BCD Overview
BCD provides a firmware-independent mechanism for manipulating boot environment data for any type of Windows system. Windows Vista and later versions of Windows will use it to load the operating system or to run boot applications such as memory diagnostics. Some key characteristics include:
BCD abstracts the underlying firmware. BCD currently supports both PC/AT BIOS and EFI systems. BCD interfaces perform all necessary interaction with firmware. For example, on EFI systems, BCD creates and maintains EFI NVRAM entries.
BCD provides clean and intuitive structured storage for boot settings.
BCD interfaces abstract the underlying data store.
BCD is available at run time and during the boot process.
BCD manipulation requires elevated permissions.
BCD is designed to handle systems with multiple versions and configurations of Windows, including versions earlier than Windows Vista. It can also handle non-Windows operating systems.
BCD is the only boot data store that is required for Windows Vista and later versions of Windows. BCD can describe NTLDR and the boot process for loading of earlier versions of Windows, but these operating systems are ultimately loaded by Ntldr and must still store their boot options in a boot.ini file.
Note: If a system includes earlier versions of Windows along with Windows Vista, the earlier versions should be installed first.
There are two approaches to modifying the settings that are contained in BCD:
Users can interact with BCD through several tools. The details of what can be modified depend on the particular tool.
Developers can programmatically manipulate a BCD store through the BCD WMI provider. The WMI provider supports a unified programming interface that can be used for both local and remote management of BCD stores. The interface is independent of the underlying firmware, so developers can write one application that works on any type of system.
Note: BCD’s data store is a registry hive, but that hive should not be accessed with the registry API. Interaction with the underlying firmware occurs in the supported BCD interfaces. For this reason, BCD stores should be accessed only through the associated tools or WMI API.
BCD Architecture
The BCD architecture is a hierarchy composed of three basic components: stores, objects, and elements.
A BCD store is the top-level component in the hierarchy. It serves as a namespace container for the BCD objects and elements that make up the contents of the store.
A BCD object is a container of BCD elements. The most common type of BCD object describes a boot environment application, such as an instance of the Windows boot loader. However, BCD objects are also used for other purposes.
A BCD element is a singular item of data such as a debugger setting, a boot application name, or an operating system device.
Figure 1 is a schematic illustration of the BCD hierarchy.
Figure 1. The BCD hierarchy
BCD Stores
A BCD store is a namespace container for BCD objects and elements that holds the information that is required to load Windows or run other boot applications. Physically, a BCD store is a binary file in the registry hive format. A computer has a system BCD store that describes all installed Windows Vista operating systems and installed Windows boot applications. A computer can optionally have many non-system BCD stores. The characteristics of BCD stores include:
The system store is a registry hive whose file is named BCD. On PC/AT BIOS systems, the file resides in the active partition's \boot folder. On EFI systems, the file is located on the EFI system partition (ESP) under \EFI\Microsoft\Boot.
The system store is used by the Windows boot manager to control boot flow. With a multiboot system, it presents a selection menu to the user.
BCD has two interfaces: the BCD WMI provider and BCDedit.exe. Both interfaces abstract the location of the system store. BCDedit.exe operates on the system store unless a specific store is specified. With the BCD WMI API, the system store is specified by an empty string ("").
Administrators or support professionals can create additional BCD stores with BCDEdit or programmatically with the BCD WMI API. Additional stores can be useful for recovery, repair, and imaging.
Administrators or support professionals can use BCDEdit or the WMI API to import a non-system store as the system store.
Figure 2 shows an example of how the BCD hierarchy is implemented in a typical BCD store.
 Figure 2. A typical BCD store
A BCD store normally has at least two and optionally many BCD objects.
A Windows boot manager object. This object contains BCD elements that pertain to the Windows boot manager, such as the entries to display in an operating system selection menu, boot tool selection menu, and timeout for the selection menus. The Windows boot manager object and its associated elements serve essentially the same purpose as the [boot loader] section of a boot.ini file. A store can optionally have multiple instances of the Windows boot manager. However, only one of them can be represented by the Windows boot manager's well-known globally unique identifier (GUID). The GUID's alias, {bootmgr} can be used to manipulate a store with BCDEdit.
At least one and optionally several Windows boot loader objects. Stores contain one instance of this object for each version or configuration of Windows Vista or Windows Server 2008 that is installed on the system. These objects contain BCD elements that are used when loading Windows or during Windows initialization such as no-execute (NX) page protection policy, physical-address extensions (PAEs) policy, kernel debugger settings, and so on. Each object and its associated elements serve essentially the same purpose as one of the lines in the [operating systems] section of boot.ini. When a computer is booted into Windows Vista, the associated boot loader object is represented by the alias {current}. When manipulating a store with BCDEdit, the default boot loader object has the alias {default}.
An optional Windows Ntldr object. The Ntldr object describes the location of Ntldr, which can be executed to boot earlier versions of Windows. It is required only if the system includes versions of Windows that are earlier than Windows Vista. It is possible to have multiple instances of objects that describe Ntldr. However, as with the Windows boot manager, only one instance can be represented by Ntldr's well-known GUID. The GUID's alias, {ntldr} can be used to manipulate a store with BCDEdit.
Optional boot applications. Stores can optionally have BCD objects that perform other boot-related operations. One example is the Windows Memory Tester, which runs memory diagnostics.
For comparison, Figure 3 shows the contents of a typical boot.ini file and how the boot.ini entries correspond to BCD objects and elements.
Figure 3. The relationship between boot.ini and BCD
Note: Figure 3 uses descriptive labels for BCD objects and elements. In practice, they are represented by names that depend on the particular tool. Some commonly used names are given later.
| 