The BCD Store


The information in these notes relates to BIOS based systems. According to available documentation (BCDEdit Reference (White Paper - dated January 31, 2008) - available here) much of it also applies to Extensible Firmware Interface (EFI) based systems -

"BCD abstracts the underlying firmware and provides a common programming interface that can be used to manipulate the boot environment for all systems running Windows Vista or later versions of Windows. Every such system has a system BCD store that contains the data that controls the boot environment. Systems can have additional BCD stores, but only one store at a time can be designated as the system store."

The white paper referenced above applies to Windows Vista/2008 - these notes are based on Windows 7. Many of the examples included in these notes are compatible with Vista/2008 tools however Windows 7 added additional features (including VHD boot options) that are not supported by older systems such as vista or the tools included with them (e.g. older versions of BCDEdit).

Previous versions of Windows NT (including Windows 2000/XP/2003) used the NTLDR boot loader - all boot menu options are contained in the plain text file boot.ini - this file can be modified with a text editor such as notepad. Windows Vista introduced the BOOTMGR boot loader, which is also used by Windows 2008/7. All boot menu options for BOOTMGR are contained in a Boot Configuration Database (BCD) Store - it is not possible to modify the menu options in a BCD store with a text editor as a binary format is used. Vista (and later) operating systems are shipped with the command-line BCDEdit tool for modifying (and creating) BCD Stores.

There are several ways of accessing information in a BCD store - although this guide focuses on BCDEdit usage it is also possible to load a BCD store as a registry hive. Entries in a BCD store are classed as objects. Each object in the store will have its own globally unique identifier (GUID) value. All GUID values use the format {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} - where x is a hexadecimal digit. These values all contain 38 characters (including the braces ({ and }) and dashes (-)). BCDEdit also uses some well-known identifiers (e.g. {bootmgr}, {ntldr}, etc - see here), however even these have their own underlying 38 character GUID value.

When a BCD store is loaded as a registry hive we can see that each Object (identifiable by its GUID value) has its own Description and Elements subkeys. The Elements key contains further subkeys relating to different datatypes - e.g the 12000004 subkey contains the Description for the object (the text that will appear in the boot menu).

Previous (NTLDR based) versions of Windows are susceptible to system device changes, which can lead to Windows not booting. The location of the windows installation is contained in the configuration file boot.ini - the entry will use arcpaths to identify the location (see here). For a typical Windows XP install the boot entry will be multi(0)disk(0)rdisk(0)partition(1)\WINDOWS. This tells Windows to boot the first partition (partition one) on the first harddisk (disk zero). The disk number is however allocated by the BIOS and can change in some situations - changing the boot device will typically change the disk order in the BIOS for example. If the disk number for the Windows installation changes then the multi(0)disk(0)rdisk(0)partition(1)\WINDOWS entry will now be pointing to the wrong device.

This is no longer an issue when using BOOTMGR to boot Windows Vista/2008/7 installations as BCD store entries can be set to identify the correct device by use of the devices disk signature and partition offset. Consequently it is possible to copy the BCD store to another device, boot the BOOTMGR boot loader from the new device (e.g. a floppy disk, CDROM or USB drive) and still load the existing operating system entries. The partition number is no longer an issue either, as once the correct disk has been identified by its signature the partition offset is automatically used. Unfortunately any legacy operating system entries (e.g. {ntldr}) could still be affected by device/partition changes.

The following REG_BINARY value can be used to illustrate the use of disk signature and partition offset identifiers in boot entries (objects). The data has been taken from a BCD store on my system (BCD Store was loaded as a registry hive - data is from Objects\{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}\Elements\11000001 key). The blue data is the partition offset (in this case the 63rd sector); the red data is the disk signature. Note/warning - the relative location of the signature and offset appears to vary between entry/disk types -

e0,34,55,ae,24,a9,6c,46,b8,36,75,85,39,a3,ee,3a,00,00,00,00,01,00,00,00,9a,
00,00,00,00,00,00,00,03,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,00,00,01,00,00,00,72,00,00,00,05,00,00,00,06,00,00,00,00,00,00,
00,48,00,00,00,00,00,00,00,00,7e,00,00,00,00,00,00,00,00,00,00,00,00,00,00,
00,00,00,00,01,00,00,00,73,ab,09,49,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,5c,00,42,00,6f,00,6f,00,74,00,
5c,00,62,00,6f,00,6f,00,74,00,2e,00,77,00,69,00,6d,00,00,00