1. BCD里面记录的，确实是分区GUID，而非 C: D: ... 盘符。而通过 bcdedit 或 easyBCD 查看到的　osdevice partition=C:　是经过“翻译”的， bcdedit 把 GUID 翻译成该分区在当前环境下的盘符

　　2. GUID 确实与 MBR 有关。我试着重现故障，在 dos 用 diskgen 2.0 重写硬盘主引导记录（MBR）后，win7果然不能启动，bootmgr找不到系统盘了。应该是GUID变化导致的。

　　linux 中，分区 UUID 与MBR无关。而微软把分区 GUID 和 MBR 扯在一起，不知道是怎么想的。或许是出于技术考虑。但客观上给 win7 与 linux 双系统用户造成了麻烦：安装 linux ，可以，安装 GRUB 不会碰触到 MBR 中与 GUID 有关的关键字段，此时 win7 可以正常启动；然而，当 GRUB 出了问题，想恢复微软MBR，可要小心了，过去惯用的 fdisk /mbr 、diskgen重建MBR 方法都有问题了。

　　3. 我试着把 iso中的 bootmgr 和 boot 目录解压到D盘，在D盘新建文件夹，命名为 sources，把 iso 中 sources 目录下的 boot.wim 解出来 放进去，重启，从 BIOS 设定的默认启动设备进入 GRUB4DOS（这一点很重要，后面详述），chainloader (hd0,4)/bootmgr ，boot ，即可进入 win7 PE ，修复引导。

　　这一点上比 xp 先进了。xp 的启动器只能从第一活动主分区载入 boot.ini。而从试验结果看， bootmgr 会默认加载同分区中的 boot\BCD ，这借鉴了 grldr 默认加载同分区 menu.lst 的特性 （呵呵，这样说有点吹捧 GRUB4DOS ，不过，的的确确是 GRUB4DOS 最先引入这一特性）。而从ISO中取来的 BCD ，又默认加载同分区中的 sources\boot.wim ：

复制内容到剪贴板
代码:
Windows Boot Loader
-------------------
identifier {7619dcc9-fafe-11d9-b411-000476eba25f}
device ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
path \windows\system32\boot\winload.exe
description Windows Setup
locale en-US
inherit {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
osdevice ramdisk=[boot]\sources\boot.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}
systemroot \windows
detecthal Yes
winpe Yes
ems Yes
这样 一来，bootmgr、boot 、sources 不再限制于主分区，放在逻辑分区也可以启动

　　4. 从U盘启动修复 win7 引导，有些麻烦。

　　这是因为 win7 修复程序会把修复的引导记录写入当前启动分区。所谓 当前启动分区 也就是 (hd0,0)。举例来说，我有两块内置硬盘 A 和 B，一块移动硬盘，BIOS 设定从 A 启动，那么启动后，硬盘A的第一活动主分区即 win7 认为的“当前启动分区”。假如启动时按 ESC 键进入选择菜单，选了从 移动硬盘 启动，那么，移动硬盘的第一分区就是 “当前启动分区” 。

　　回到正题，从U盘启动，假如是ZIP模式，即 U盘在 bios 里映射为 0x00，盘符为A，那么， “当前启动分区” 是 BIOS 设定的第一硬盘的第一分区，也就是正常的启动分区，此时修复程序会把 win7 引导写入该盘，重启后，就会进入win7菜单，一切OK。光盘启动与此类似，只不过变成 0xff 。

　　然而，如果U盘是以HDD模式启 动，那么，进入 WIN7 PE后，U盘第一分区将成为 “当前启动分区” ，修复的引导将被写入U盘第一分区，而内置硬盘上的引导 故障依旧。当你摘下U盘，从内置硬盘启动时，依旧不能进入 win7 。移动硬盘也有类似问题。