History
As you all know, when a system is booted or restarted it must load an operating system. To do this, the system must have some preset location or locations (hard drive, network, or some other source) to determine when a boot or restart occurs. Different system architectures have different presets. This means that Windows must have a method to find this information on various architectures. 

For most PCs, the boot occurs from the local hard drive. A formatted local hard drive that is bootable contains a Master Boot Record (MBR) that the BIOS (Basic Input/Output System) reads on startup. The MBR is always located on the first sector of the disk and contains two items: 1) the Master Partition Table; and 2) the Master Boot Code. The Master Partition Table contains the description of the disk layout in terms of partitions. The Master Boot Code contains a small initial boot program that the BIOS loads and executes to start the boot process. When the boot program finishes executing, it is responsible for transferring control to the loaded O/S.

In the case of Windows, the boot program transfers control to NTLDR, which is responsible for displaying the Windows startup menu. NTLDR is also responsible for helping load the selected Windows O/S. How does NTLDR know which Windows operating systems are available? On an x86 system this information comes from a file named "BOOT.INI" that is located in the root directory of the drive containing the booted MBR. This file is a standard text file, editable via a text editor, which contains the following configuration information:

• Each bootable operating system on the system.
• The default booting operating system.
• A default time out for the NTLDR display, if multiple operating system installations are present.

Out with the Old, In With the New
Recently a new specification called the Extensible Firmware Interface (EFI) was created. According to Intel:

EFI defines a new model for interface between operating systems and platform firmware. The interface consists of data tables that contain platform-related information, plus boot and runtime service calls that are available to the operating system and its loader. Together these provide a standard environment for booting an operating system and running pre-boot applications.

Since Vista must support both EFI and BIOS-based computers, a new data store called the Boot Configuration Data (BCD) store was created to abstract the underlying firmware (BIOS or EFI).  This BCD store supplants, and essentially serves the same purpose as BOOT.INI. In order to manipulate the data contained in BCD, which is in binary format, the user can either use BCDEDIT or MSCONFIG.

Note: BOOTCFG is still around, but if present, it only operates on a BOOT.INI file.  Therefore, if you have a Vista system that has a legacy O/S installed, you can use BOOTCFG to modify it.

BCDEDIT
BCDEDIT is a command line tool that requires administrator access (i.e., right-click command prompt in the start menu and select run as administrator). BCDEDIT can be used to view and manipulate data contained in the BCD store. The BCDEDIT interface provides the following types of commands:

• Commands that operate on a BCD store.
• Commands that operate on entries in the BCD store.
• Commands that operate on entry options.
• Commands that control output.
• Commands that control the boot manager.
• Commands that control Emergency Management Services.
• Commands that Control Debugging.

Descriptions of each of the commands can be obtained via the help information contained in BCDEDIT itself (BCDEDIT /?, or BCDEDIT /? /bcdoption, where "bcdoption" is a supported command).

Rather than explaining all the capabilities of BCDEDIT, the rest of this section focuses on the common operations a developer might use to modify the system's boot behavior.

Obtaining List of Current Bootable Operating Systems
The first function that all developers need is a way to list what bootable operating systems are available on a machine. This is where the "/enum" command is useful. BCDEDIT supports the /enum command to control output and it represents the default command processed when running BCDEDIT without parameters.

The output of the "BCDEDIT /enum" command displayed in Figure 1 shows the boot enviroment split into two categories: 1) the Windows Boot Manager; and 2) the various boot applications (identified as "Windows Boot Loader" entries) that run in the boot environment. The Windows Boot Manager is a mini-operating system that controls the boot and enables you to choose which boot application to run.

There will be one boot application for each Vista installation on your computer and one legacy entry that uses NTLDR and boot.ini to allow booting into pre-Vista operating systems such as Server 2003 and XP. You'll notice that Figure 1 lists three boot application entries with the descriptions, "Microsoft Windows", "Mark", and "copy of mark", all of which point to the same boot operating system. On reboot, the Windows Boot Manager will list these three boot application entries as choices for booting (Note: the "/enum" command supports a "/v" attribute that displays more verbose output).

Creating Boot Entries in the BCD Store
The next function a developer will want is a way to copy, create, or delete entries in the store. The "BCDEDIT /copy" command allows you to create a new boot application by copying an existing entry. Of course, there is a caveat - entries are identified by Global Unique Identifiers (GUIDs), and you'll have to know what it is in order to copy or delete the entry. The identifier can be found by using the "BCDEDIT /enum [/v]" command. Each entry lists its identifier and other settings as shown previously in Figure 1.

Figure 1 - BCDEDIT /ENUM output

So, to copy the default boot application to a new boot application that has a description of "Mark", issue the following command:

"BCDEDIT /copy {default} /d "Mark"

Likewise, if you want to delete an entry, issue the "BCDEDIT /delete {id}" command where "{id}" is the identifier of the boot application to be deleted.  For example, to delete the entry "copy of mark" (as defined in Figure 1):

"BCDEDIT /delete {50c73d50-e6b3-11da-bc73-d30cdb1ce216}

Figure 2 shows what the Windows Boot Manager displays if the BCD contained two entries whose descriptions are "Microsoft Windows" (which is the default name of a Vista install) and "Mark."

Figure 2 - Boot Manager Display

Modifying Settings for Individual Entry
Another common function is modifying the settings of an individual boot application entry. As in the previous section, in order to perform this command you must know the identifier of the entry you want to modify. In addition, you need to know the application and the data type of the data to be modified because it uniquely identifies both the data format and meaning of the value. BCDEDIT allows the user to modify the settings for the following types of applications:

• BOOTAPP - Boot applications
• BOOTMGR - Boot manager
• BOOTSECTOR - Boot sector application
• CUSTOMTYPES - Custom types
• FWBOOTMGR - Firmware boot manager
• MEMDIAG - Memory diagnostic application
• NTLDR - OS loader that shipped with earlier Window OSes
• OSLOADER - Windows Vista O/S Loader
• RESUME - Resume Application

BOOTAPP and OSLOADER are of most interest in this list. The BOOTAPP type allows the user to modify the debug settings of individual boot application. The OSLOADER type allows the user to modify options like HAL, KERNEL, ONECPU, and REMOVEMEMORY to name a few.

Another capability of BCDEDIT is controlling which operating system is to be booted. This can be done using either the "/bootsequence" or "/default" options. The "/bootsequence" option allows you to specify a one-shot boot sequence for the system, while the "/default" option allows you to specify the default boot application such as the O/S that will be the default.

Enabling and Setting Debug Options
Probably the most useful settings to manage with BCDEDIT are those related to debugging. BCDEDIT provides the "/debug" and "/dbgsettings" options. The "/debug" option allows the user to enable or disable debug mode for either the current or specified Windows O/S installation (i.e., "BCDEDIT /debug ON" for the current entry). The "/dbgsettings" option allows the user to view or set the global debugger settings for the system (for example, "BCDEDIT /dbgsettings 1394 channel:62").

Another option you may desire is setting up an alternative HAL and KERNEL, if you want to debug using a partially checked Vista build. To do this you must use the following commands to set up the HAL and KERNEL for the current boot entry:

bcdedit /set HAL hal.chk
bcdedit /set KERNEL ntoskrnl.chk

Remember that you will need to use the correct HAL and KERNEL for your system. As of build 5472 of the WDK, the HALs and KERNELs needed for Vista, x86, X64, and IA64, are contained within the debug directory of the WDK along with their symbols. It's easy to find the correct HAL and KERNEL to use for your platform if you have an x64 or ia64 system, because there is only one choice. However, if you have an x86 system you will have to do some research. In Vista the "Windows\Repair\Setup.log" has been moved to \Windows\Inf and split up into "Setupapi.dev.log" and "Setupapi.app.log". So, in order to find the HAL you need, look in "Setupapi.dev.log." The format of this file is vastly different from the old "repair\setup.log" file. Just search for hal.dll to find the HAL that was installed. If you're using the x86 kernel, you will have to use the debugger's LM command to verify what was installed on your system. This can be done by using the "lmv mnt" command to find the KERNEL and the optional "lmv mhal" command to find the installed HAL.

Disabling 64bit Signing Requirements for Testing
Another important use of BCDEDIT is disabling Vista's 64-bit signing requirements while testing your driver. To do this you must perform the following operations:

1. Enable debugging on your system by issuing the command "BCDEDIT /DEBUG ON."
2. Enable prerelease test code signing certificates by issuing the command "BCDEDIT /SET TESTINGING ON."
3. Prevent the OS loader from performing code integrity checks by issuing the command "BCDEDIT /SET NOINTEGRITYCHECKS ON." Note that  "NOINTEGRITY CHECKS" will be removed in future versions of Vista. So this is only needed for Beta 2.
4. Reboot the system with a debugger attached.
5. When the system restarts, use "F8" to get to the "Advanced Boot Options" menu. Next, select the "Disable Driver Signature Enforcement" option as seen in Figure 3.

Figure 3 - Boot Manager Advanced Boot Options

Well, there you have it - the basics for working with BCDEDIT. Now let's move on to MSCONFIG.

MSCONFIG
For those who just need to modify the boot settings of an existing operating system, it is best to use MSCONFIG. MSCONFIG includes a GUI, shown in Figure 4, which makes it easy to use.

The dialog in Figure 4 lists the bootable operating systems contained in the BCD store. This allows the user to manipulate boot settings of the selected operating system, such as Safe Boot. It also allows the setting of global values, such as the timeout for O/S selection. The "Advanced Options" button can be used when advanced modifications to the booting   O/S are required (See Figure 5).

Figure 4 - MSCONFIG

Figure 5 - MSCONFIG BOOT Advanced Options

From the BOOT Advanced Options dialog, the user can modify the global debug settings. Notice that I mentioned global debug settings. Unlike previous versions of Windows where each line in the BOOT.INI file could have separate debug options, Vista has one set of debug options that are used by all Vista O/S installations on your machine.

Summary
As PCs change, the traditional interfaces we use to control how the PC boots and which mode it boots in also change. Vista's support of both old BIOS-based PCs and new EFI-based machines is evidence of this change. BCDEDIT and MSCONFIG are the tools that Microsoft provides to help with this transition. This article should also provide you with the basic information needed to make using these tools easier.