Windows 2008 R2引导过程

我一直难以理解我正在经历的一些行为，我希望那里的某些人可以帮助启发我一点。

我想我的问题归结为：Windows启动过程具体如何确定VBR / bootsector在磁盘上的位置，用于Windows 2008 R2中的“启动”分区？

我的问题的背景如下。

我有一个非常开心，功能正常的2008R2（VM）安装，它包含标准的100 MB系统保留分区，后跟'boot'（C:\）分区。出于教育目的，我将C:\分区正好移动了1MB到系统分区的“右侧”（使用gparted），这在两个分区之间插入了1MB（2048扇区）的间隙。

此过程正确更新了MBR中的分区条目，以及修改了引导C:\扇区的“保留/隐藏扇区”字段。

但是现在Windows无法启动（它会导致启动管理器错误“ 0xc0000225” - 无法访问所需的设备。）。并且修复安装甚至无法找到要安装的Windows安装。请注意，如果我将驱动器安装在另一台Windows机器上，那么这些卷是健康且可行的。此外，如果我将C:\分区移回原来的位置，一切都会启动。

因此，如果MBR指向正确的偏移量，为什么Windows C:\在移动时找不到/加载分区？

首先，您应该注意C：分区上的VBR不参与引导过程。“system”分区上的VBR加载bootmgr，它从C：分区加载Windows内核。

我自己就试过这个。方便的是，运行bcdboot会在BCD中生成一个新的启动项，因此我们可以轻松地将旧条目与新条目进行比较，以查看更改的内容。

使用bcdedit我们可以看到设备和osdevice选项是不同的：

C:\Windows\system32>bcdedit /enum /v

Windows Boot Manager
--------------------
identifier              {9dea862c-5cdd-4e70-acc1-f32b344d4795}
device                  partition=\Device\HarddiskVolume1
description             Windows Boot Manager
locale                  en-us
inherit                 {7ea2e1ac-2e61-4728-aaa3-896d9d0a9f0e}
default                 {fde483f1-1482-11e2-90a1-00505698002c}
resumeobject            {fde483f0-1482-11e2-90a1-00505698002c}
displayorder            {fde483f1-1482-11e2-90a1-00505698002c}
                        {7409376c-f38e-11e1-bc89-00505698002c}
toolsdisplayorder       {b2721d73-1db4-4c62-bf78-c548a880142d}
timeout                 30

Windows Boot Loader
-------------------
identifier              {fde483f1-1482-11e2-90a1-00505698002c}
device                  partition=C:
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-us
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
osdevice                partition=C:
systemroot              \Windows
resumeobject            {fde483f0-1482-11e2-90a1-00505698002c}
nx                      OptIn
detecthal               Yes

Windows Boot Loader
-------------------
identifier              {7409376c-f38e-11e1-bc89-00505698002c}
device                  unknown
path                    \Windows\system32\winload.exe
description             Windows 7
locale                  en-US
inherit                 {6efb52bf-1766-41db-a6b3-0ee5eff72bd7}
recoverysequence        {7409376d-f38e-11e1-bc89-00505698002c}
recoveryenabled         Yes
osdevice                unknown
systemroot              \Windows
resumeobject            {7409376b-f38e-11e1-bc89-00505698002c}
nx                      OptIn

不幸的是，bcdedit没有告诉我们信息是如何存储的，因此我们必须查看BCD文件本身。您可能已经知道，BCD文件实际上是一个注册表配置单元，它通常被加载到HKLM\BCD00000000，所以我们可以使用regedit或使用reg export来检查它。

每个条目的标识符是包含设置的注册表项的名称。设置本身是子键，按照它们在bcdedit输出中显示的顺序排列。事实证明（不出所料）在每个条目中，设备和osdevice包含相同的数据，并且这些数据对于功能条目而言与旧条目不同。

在我的系统上，它出现在功能条目中：

"Element"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,06,00,00,00,00,\
  00,00,00,48,00,00,00,00,00,00,00,00,00,80,06,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,01,00,00,00,b0,5d,de,33,00,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

这出现在旧条目中：

"Element"=hex:00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,06,00,00,00,00,\
  00,00,00,48,00,00,00,00,00,00,00,00,00,50,06,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,01,00,00,00,b0,5d,de,33,00,00,00,00,00,00,00,00,00,00,00,\
  00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00

只有一个区别。让我们更好地格式化旧条目：

0000 00,00,00,00,00,00,00,00,
0008 00,00,00,00,00,00,00,00,
0010 06,00,00,00,00,00,00,00,
0018 48,00,00,00,00,00,00,00,
0020 00,00,50,06,00,00,00,00,
0028 00,00,00,00,00,00,00,00,
0030 00,00,00,00,01,00,00,00,
0038 b0,5d,de,33,00,00,00,00,
0040 00,00,00,00,00,00,00,00,
0048 00,00,00,00,00,00,00,00,
0050 00,00,00,00,00,00,00,00

在新条目中，字节0x0022是0x80而不是0x50。碰巧的是，我将分区移动了3MB，所以我怀疑这是偏移的一部分。让我们看看如果我再移动4MB（总共7MB）并创建一个新的BCD条目会发生什么呢？好的...... 0x80变为0xC0，因此一致。

一个明智的猜测是，从0x0020开始的八个字节（或者可能是十六个？）是分区开始的字节偏移量。0x06C00000的值是113246208或者恰好是108MB; 检查分区表我发现这确实是分区的开始。QED。:-)