Windows 2008 R2 Boot process

I have been stumped trying to understand some behavior I am experiencing and I was hoping someone out there could help enlighten me a bit.

I think my question boils down to this: How specifically does the Windows boot process determine a VBR/bootsector's location on disk for the 'boot' partition in Windows 2008 R2?

The background to my question is as follows.

I have a perfectly happy, functioning installation of 2008R2 (VM) that contains the standard 100 MB system reserved partition, followed by the 'boot' (C:\) partition. For educational purposes, I moved the C:\ partition exactly 1MB to the "right" of the system partition (using gparted), which inserted a 1MB (2048 sector) gap between the two partitions.

This process correctly updated both the partition entry in the MBR, as well as modifying the C:\ bootsector's "reserved/hidden sector" field.

But now Windows will not boot (it gives a Boot Manager error "0xc0000225" - a required device is inaccessible.). And a repair install cannot even find the Windows installation to repair. Mind you, if I mount the drive on another Windows machine, the volumes are healthy and viable. Also, if I moved the C:\ partition back to its original place, everything boots right up.

So, given the MBR is pointing to the correct offset, why can't Windows find/load the C:\ partition when it has been moved?

First off, you should note that the VBR on the C: partition isn't involved in the boot process. The VBR on the "system" partition loads bootmgr, which loads the Windows kernel from the C: partition.

I've just tried this myself. Conveniently, it turns out that running bcdboot generates a new boot entry in the BCD, so we can easily compare the old entry with the new one to see what's changed.

Using bcdedit we can see that the device and osdevice options are different:

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

Unfortunately bcdedit doesn't tell us how the information is stored, so we'll have to look into the BCD file itself. As you might already be aware, the BCD file is actually a registry hive, and it's normally loaded into HKLM\BCD00000000, so we can examine it with regedit or using reg export.

The identifier for each entry is the name of the registry key containing the settings. The settings themselves are subkeys, arranged in the same order as they appear in the bcdedit output. It turns out (unsurprisingly) that in each entry, device and osdevice contain the same data, and this data is different for the functioning entry than for the old one.

On my system, this appears in the functioning entry:

"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

and this appears in the old entry:

"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

There's only one difference. Let's format the old entry a little bit more nicely:

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

In the new entry, byte 0x0022 is 0x80 instead of 0x50. As it happens, I moved the partition by 3MB, so I suspect that's part of a offset. Let's see what happens if I move it another 4MB (for a total of 7MB) and create a new BCD entry, shall we? OK ... the 0x80 becomes 0xC0, so that's consistent.

A sensible guess would be that the eight bytes (or perhaps sixteen?) starting at 0x0020 are the byte offset of the start of the partition. The value of 0x06C00000 is 113246208 or exactly 108MB; examining the partition table I find that is indeed the start of the partition. QED. :-)