Vista's Boot Files

How the Vista boot process works.
The problems of moving an install of Vista.
A new Vista specific issue for third-party bootmanagers.

The information on this page also applies to Windows 7.

In Windows 2K, XP and 2K3 the three boot manager-loader files are ntldr, Ntdetect.com and boot.ini and all three are in the root of the active primary partition of the boot hard drive (the System partition). With Vista these three files have been replaced with bootmgr, BCD and winload.exe, but only bootmgr and BCD stay in the root of the system partition and winload.exe now resides in the Windows/system32 folder of the Boot partition. (Of course the system and boot partitions can be the same partition if there is no Windows dual or multiboot configured). The BCD (Boot Configuration Data) file has replaced the boot.ini file. The bootmanager function that was a part of ntldr is now carried out by bootmgr. The other functions of ntldr and those of Ntdetect.com of setting up the correct environment for Windows are now both carried out by winload.exe. The rest of the boot process remains the same, ntldr and winload are the bootloaders that start the operating system by loading ntoskrnl.exe, hal.dll and the System registry hive.

Method of Operation
In old WinNT the ntldr uses the boot.ini file to locate hard drives and partitions and a typical line for a PC/AT BIOS computer with IDE or SATA hard drives may look like this - multi(0)disk(0)rdisk(0)partition(1)\WINDOWS........ The ntldr knows from the information here that it has to go to partition number one on hard drive zero. It consults the computer's firmware (BIOS) to find out which hard drive is considered to be drive zero, then looks at the partition table on that drive to find out which partition is number one. Once it knows the location of the partition it can then find the Windows/system32 folder of the OS it has been asked to start.

In Vista the bootmgr consults the BCD file for the information it needs to find the correct drive and partition, but it does not use the firmware to find the hard drive, or the partition table to find the partition. Instead it uses the unique Disk Signature in the MBR of a hard drive and the partition offset (starting sector) of a partition.

Inside the BCD store each boot item is in its own little container (Object) and many of these Objects hold details of the disk signature of the hard drive and the starting sector of the partition where the item to be started is located. Each Object is labeled with a 32 digit alpha/numeric number called a GUID number. When bootmgr is asked to start a boot item it identifies the item's Object by its GUID number and then reads the disk signature and partition offset information that is contained in that Object. Bootmgr then scans the connected hard drives until it finds the drive with that disk signature and then jumps straight to the desired sector on that hard drive by using the partition offset information. The BIOS no longer has to be consulted to find the hard drive because bootmgr is not looking for a specific number of drive but just scanning all drives for a disk signature. The partition table on the drive does not have to be consulted because bootmgr does not need to know the number of the partition or be told where that partition is.

In some respects this new method could be seen as an improvement on how ntldr locates a drive and partition. It means that Vista is not wholly dependent on the configuration of drives and partitions remaining completely static. A change to the partition's number (by changing other partitions on the drive), or moving the position of a hard drive in the computer, will have no affect on bootmgr's ability to start any Vista OS that a BCD Object holds valid signature and offset information for. Of course bootmgr will still have to be on the boot hard drive, or even a boot floppy, but the OS itself can have its partition number changed or its hard drive moved in the machine. As long as the disk signature on a hard drive and the starting offset of the Vista partition still matches the ones in the Object, then bootmgr will find the OS. (If you are using the Vista bootmanager to dual or multiboot with an earlier WinNT OS then you will still need to update its boot.ini after configuration changes.)

Moving Vista
There is a definite downside to this new arrangement for anyone who wants to move an install of Vista to another partition or hard drive. If either the signature or offset on the drive no longer match those that were written into an Object, then bootmgr will not be able to find the bootloader and so will give the error message that "winload.exe.....is missing or corrupt". (For Windows 7 see winload.exe....is no longer missing). Of course winload.exe is in perfect working order and located where it should be within the OS, it is just that bootmgr is getting the wrong numbers from the Object on where to look for it. The information in the Object will need to be updated to correctly reflect new signature and offset details. If you are using the Microsoft bootmanager and just have a simple set up of no more than a dual or maybe triple boot then the auto-repair from the Vista DVD might do this for you, that is if you have a full Vista DVD. For the slightly more able computer user the bootrec.exe tool can be used, and for the real experts there is the command line BCDEdit.exe tool. If you are using a third-party bootmanager and your Windows installs are all independent then the DVD Auto Repair would be best avoided as it will try to configure the Windows bootmanager. (If you don't know what I mean by 'Independent' then try the guide here). How to use BCDEdit.exe to update the BCD is explained on the cloning page.
You can also find an updated article on this topic here.

There are GUIDs and then there are GUIDs.
In the BCD store the boot Objects are identified by their GUID numbers, but not all GUIDs are the same. Some are called Globally Unique Identifiers and some are Global Universal Identifiers. The 'Unique' GUIDs are generated for each Vista boot and resume Object and will be unique to that Vista install. They appear to be randomly generated and can have any value. I've found that as long as the GUID held in the bootmgr Object matches the one for the Vista Object, I can change them to any 32 digits I want and everything seems to function normally. The 'Universal' GUIDs have a fixed value, which again appears arbitrary, that will be the same on every computer. The BCD contains separate boot Objects for things like the Memory Tester {memdiag} and the Legacy OS Loader {ntldr} and these Objects have 'Universal' GUIDs. Such Objects still contain the signature and offset of the drive and partition where the item is located and bootmgr does use this information to find it, so configuration changes do have an affect.

In Vista the BCD file will be open and held open permanently by the operating system. The primary reason for this may be for the hibernation function so that the BCD can be quickly reset for next boot to start the resume loader instead of winload.exe. My tests have shown that this is indeed what happens and the BCD is modified before hibernation shuts the computer down. The new Vista 'Hybrid Sleep' is both sleep and hibernation and also sets the BCD in the same way that hibernation does, at least as far as I can tell. Other things that take advantage of the BCD always being open are the msconfig utility and the System Control Panel, both of which have options to make small non critical changes to a few BCD boot settings. The BCD is not held open in XP if you are dualbooting Vista and XP with the MS bootmanager, even though the BCD will be used by bootmgr to start the XP ntldr. (If however you run BCDEdit.exe inside XP on a BCD you have moved into XP for editing then it will be opened into the system and remain open until XP is rebooted).

The Wrong BCD
Because of the way the Microsoft bootmanager works the Vista operating system expects that the BCD will always be on the system partition, so during bootup the Vista OS opens the system partition BCD. When using the Microsoft bootmanager the system partition is always the active primary partition on the drive seen in the BIOS as the first boot hard drive, even if that is not the partition you are actually running Windows from. When using a third-party bootmanager the system partition is usually the partition you are booted in to, even if that is on a second or higher hard drive or a logical partition, which means that the BCD inside your booted Vista is not necessarily on the boot drive active primary. Unfortunately and rather inconveniently when Vista boots up it is not the system partition as seen by Vista itself that is chosen for the location of the BCD to open, but instead the partition that Windows considers should be the system partition, namely the boot drive active primary. If there is another BCD to be found in the correct location on the expected system partition then it will be that BCD that will be held open in the Vista you are booted into, even if the partition that this BCD is on has been hidden. If there is no BCD to be found on the supposed system partition then none at all will be opened. To check if the BCD inside your Vista is the one being used then try to open it in notepad, or copy and paste it somewhere. If it is the one currently open in the system then you will fail and get a message that it is being used by another process or program.

Resulting problems
If you let Vista hibernate or hybrid sleep when the wrong BCD is open in the system then it will be that wrong BCD that will be set to start the resume loader. This causes hibernation not to function correctly, but hybrid sleep on the other hand may partly still function as it should. If there has not been a power outage while the machine is in hybrid sleep then it will wake in the normal sleep manner, without having to use the hibernation component. If there has been a power outage, or if the machine has chosen by itself to go into full hibernation to save power, then on restart the resume loader will be required, but because the BCD inside the operating system was not the one that was set to resume you will only be presented with the bad shutdown menu, where choosing to boot normally will start Vista in a normal bootup. One other consequence worth mentioning is that if you boot the OS that did have its BCD set for hibernation, but only if it's before the OS that set it is rebooted, then resume will function and will actually restore the Vista OS that set the hibernation. This is because that when the BCD is modified for hibernation it is keyed to target the resume loader by the disk signature and the partition offset of the OS that hibernation was triggered from. If you are using a bootmanager that hides other partitions then the resumed Vista's partition may be hidden from itself, so it won't be mounted and you will have an unusable system.
Also see Hibernation and Third-Party Bootmanagers.

Microsoft's supplied tool for configuring the BCD store is the command line BCDEdit.exe, which can be run from inside Windows or from the Vista DVD. When used from inside Vista it will by default read and work on the BCD that is already held open in that operating system, which means you could inadvertently make changes to a BCD other than the one you intended. If no BCD is currently open then BCDEdit.exe will look for one on the boot drive active primary, which will not have one or it would already be open. BCDEdit.exe will then report that the BCD could not be found. Changing the active partition before running BCDEdit.exe will not help if there is already a BCD being held open. The msconfig utility and the System Control Panel options will also change the wrong BCD, or be unavailable if no BCD is open. How to point BCDEdit.exe to work on your desired BCD is covered on the cloning page.

A Solution for This?
This issue only applies to independent Vista installs on second or higher hard drives or logical partitions and if you are using a third-party bootmanager that is not fully Vista compatible. If you completely turn off hibernation and are aware that using BCDEdit.exe and msconfig etc could change the wrong BCD, then perhaps there are no other consequences to this issue and it can be lived with. To solve this issue for second or higher hard drives your bootmanager must be able to 'Drive Swap' correctly so that Vista does see the drive as the boot hard drive. So far I have only tested three bootmanagers that can drive swap in the manner required XOSL, Boot-Us and BootIT-NG. If you have a built in function-key bootmenu to your motherboard then this of course does the job, as will manually changing the bios boot order. For logical partitions you will need a bootmanager that can set logicals as active and remove all active flags from primary partitions. The only ones I've tested to date that can do this are XOSL and BootIT-NG

It seems there is a way to specify the system BCD store on machines with EFI firmware, - this MS Document, updated 5th Feb 08, page 22, the 'sysstore' command. I cannot find a single other reference to this anywhere, so don't know if it could be made to provide a solution to this issue for BIOS-based systems. If you know anything about this then please share it via the feedback form.