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?

  • Presumably gparted inserted an empty partition between the two NTFS partitions, so perhaps the boot manager is trying to boot the second partition, which is now empty? Have you tried using bcdboot (when the drive is mounted on the other machine) to repair the boot entry? – Harry Johnston Oct 10 '12 at 20:30
  • @Harry Johnston- Thanks for the reply. Checking the MBR reveals that there are only 2 partitions, just with a gap between them. I haven't used bcdboot explicitly, but I think that the Windows RE boot tried it and failed. However, I'm more interested in why this is happening than fixing it (seeing as I intentionally broke it in the first place) – James Oct 10 '12 at 21:05
  • I'm not sure whether having a gap between partitions is allowed. What happens if you explicitly create a new partition in the gap? I also suggest trying bcdboot explicitly, on the grounds that knowing what does or doesn't fix the behaviour gives you information about the possible causes. – Harry Johnston Oct 10 '12 at 22:31
  • @Harry Johnston- So it turns out that was a good tip, thanks. Manually running bcdboot from a command prompt of the Windows RE did fix the problem. What's odd is it didn't appear to alter the MBR or the Bootsector for the second partition (all the values are the same). I will try reverting and making a tiny partition out of the 'gap' and see what effect that has next. So does this mean the the 'system partition' and/or the BCD contain a sector offset to the location of the VBR? I can't find that in any documentation, but that appears to be the behavior I'm seeing. – James Oct 11 '12 at 17:25

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}
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:


and this appears in the old entry:


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. :-)

  • Also, the four bytes at 0x0038 are the disk's signature (which can be found at 0x01b8 in the MBR). – Harry Johnston Oct 11 '12 at 21:33
  • Woah, that is fantastic sleuth-work, and exactly explains what I was seeing. You, Mr. Johnston, are my new hero. – James Oct 12 '12 at 18:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.