Why does a cloned Windows 7 BCD contain incomplete data (and, therefore, prevent booting)?

Posted on


I have had the misfortune to need to clone a dual-booting Windows XP/7 box to replace its hard drive with a smaller one. I had great trouble getting it to boot and would like to understand what’s going on and if I could be doing anything better.

Background: the machine has a 750Gb drive with 3 partitions on it:

  • Windows XP
  • Windows 7
  • Data

The original installation was done in such a way that there is no separate Windows 7 recovery partition. I hope this fact simplifies things somewhat.

I am replacing it with an 80Gb drive. The partitions have already been shrunk from within Windows 7 so that they fit onto the smaller disk.

I used GParted (from a PartedMagic Linux LiveCD) to copy the partitions across. I mark the Windows XP partition as the active partition (the same as on the original disk).

I was unable to use CloneZilla or do an entire disc copy due to the transition from a larger to a smaller disk.

After copying the partitions, I manually copied the boot loader across (taking care not to copy the partition table):

$ dd if=/dev/sda of=/dev/sdb bs=446 count=1

I removed the original disk, set the new one so it is physically connected the same as the original (IDE channel 1 master) and tried booting. This successfully presented the boot menu but failed upon selecting either option (there are two: one for XP and one for Win7).

I did a fair bit of research which let me to realise the Windows 7 boot configuration data did not contain everything it should. I compared the BCD output from the original and new disks and noted that the device entries on the latter were unknown. So I manually changed them to match the original – like this:

$ bcdedit /set {ntldr} device partition=C:
$ bcdedit /set {default} device partition=D:
$ bcdedit /set {default} osdevice partition=D:

and rebooted. This time I could boot both XP and Win7. I need to do more testing because there appears to be other differences between the two BCDs, but making the above changes at least allowed booting to take place.

So my question is really to ask why the BCD on a cloned partition would appear different to the original, and sufficiently so to prevent booting ?

And a follow up to that would be to ask if I should be doing this another way?


After cloning partitions containing Windows operating systems, it is necessary to fix up the boot configuration data if the cloned partitions are not in exactly the same position on the cloned disc as they are on the original.

The Windows boot mechanism, since Windows Vista, stores its configuration as “Boot Configuration Data” (BCD) and this refers to partitions, not by partition numbers but by a disk signature and sector offset. The disk signature is a 32-bit value embedded in the Master Boot Record. Copying the first 446 bytes of sector 0 will copy the disk signature.

If cloning activities result in the cloned disk partitions having different starting sector addresses then the original ones (highly likely unless a whole-disk clone was used) then the clone will most likely fail to boot until these remedies are applied.

Basically, the sector offsets need to be updated and, for this, you’ll need to use a recovery console (this is available on a Windows 7 install DVD). Ensure only the cloned drive is attached and boot from a Windows 7 install DVD. At the first screen make language selections and hit “next”. At the next screen (where “install now” is displayed) press SHIFT+F10 to get a command prompt.

First, confirm the drive letters that are in place and the partitions to which they relate:

list volume

Also, if you need to, re-confirm the active partition:

select disk 0
select part 1
detail part
select part 2
detail part
... and so-on

On a BIOS system, the BCD is stored in a file at X:BootBCD where X is the drive letter
of the active partition (for UEFI it’s in the EFI System Partition). Normally hidden, it can
be seen with

dir /AH X:Boot

It can be backed up like this:

bcdedit /export X:pathtobcdbackup

and restored

bcdedit /import X:pathtobcdbackup

If a disk has multiple operating systems on it, there may be multiple BCDs. The active BCD is the one in at BootBCD on the partition that is marked as active – the active partition. To list its contents (in increasing order of verbosity:)

bcdedit /enum
bcdedit /enum ALL
bcdedit /enum ALL /v

To fix up the active BCD, establish the drive letters for the correct partitions and do:

bcdedit /set {default} osdevice partition=X:
bcdedit /set {default} device partition=X:
bcdedit /set {bootmgr} device partition=X:
bcdedit /set {memdiag} device partition=X:
bcdedit /set {ntldr} device partition=X:

or, to fix up another BCD (at “X:bootbcd” in these examples):

bcdedit /store X:bootbcd /set {default} osdevice partition=X:
bcdedit /store X:bootbcd /set {default} device partition=X:
bcdedit /store X:bootbcd /set {bootmgr} device partition=X:
bcdedit /store X:bootbcd /set {memdiag} device partition=X:
bcdedit /store X:bootbcd /set {ntldr} device partition=X:

For example, my system which has XP and 7 and they show XP as being on C: and 7 being on D: and the active partition is C:. then the active BCD will be at c:bootBCD. The boot manager will be found at C:bootmgr and the memory diagnostic will be at C:bootmemtest.exe, The required commands would be:

bcdedit /set {ntldr} device partition=C:
bcdedit /set {memdiag} device partition=C:
bcdedit /set {bootmgr} device partition=C:
bcdedit /set {default} device partition=D:
bcdedit /set {default} osdevice partition=D:

With those changes, rebooting the computer (Pressing Alt-F4 will achieve this) and removing the DVD allowed the system to boot successfully.

Further Reading:

(a whole-disk clone should not suffer these issues because the partition layout on the copy should be exactly the same as the original)

According to this unofficial documentation on BCD internals, partitions in the BCD store are actually identified by the disk signature and the partition offset. You copied the disk signature (MBR bytes 440–443), but most likely changed partition offsets when putting partitions on a smaller disk, therefore BOOTMGR was no longer able to find these partitions.

Leave a Reply

Your email address will not be published.