Build a Bootable BCD from Scratch with Bcdedit
Build a Bootable BCD from Scratch with Bcdedit
Manipulate the Boot Configuration Data file
In "Fix Unbootable Systems with Bootsect" (June 2011), I talked about how to fix a Windows 7/R2 system that can’t boot, and I bolstered that discussion with an explanation of the Windows 7/R2 boot record and the Bootmgr application. Once Bootmgr starts up, though, it needs some marching orders, and it gets those from a binary file called the Boot Configuration Data (BCD) file, which usually lives in a folder named \boot on the active partition. Youuse Bcdedit to configure the BCD file. You've already read about Bcdedit in my explanations of how to create or modify “OS entries” (instructions for how to boot OSs on the system’s hard drives), but all I’ve really explained so far is how to use Bcdedit to modify anexistingBCD. This month, I'll show you how to build a bootable BCD from scratch.
A working BCD file typically contains at least two objects. First, it has a Boot Manager, which contains overall boot information such as which OS entry to boot by default and the amount of seconds to wait for the user if more than one OS entry exists. Second, it contains at least one OS entry. Here’s how to create them.
Start by deleting any existing BCD files and creating a new empty BCD file. Bcdedit quirkily requires you tofirstcreate a new BCD file somewhere andthen“import” it—a process that copies whatever is in the new BCD file into the “official” BCD file in \boot on the active volume. You can do that by typing two commands into an elevated command prompt:
bcdedit /createstorebcd
bcdedit /import bcd
These commands work whether you already have a \boot\bcd in place or if you’re working from a toasted boot volume that lacks any BCD file at all. Now that you’ve done that, the “sacrificial" BCD file is no longer necessary, so you can delete it:
delbcd
Next, create the Boot Manager piece of the BCD file by typing
bcdedit /create {bootmgr}
Note the /create option in this command instead of the /createstore option in the earlier command. You’ll use the former quite often in BCD work and the latter much less so. The /create option lets Bcdedit create several different kinds of BCD objects. Invoking it with the {bootmgr} identifier creates that overall Boot Manager section. (Note that I haven't included a description with the /d option, despite the fact that every example I can find on the Webdoes.It’s superfluous when creating a Boot Manager object.)
The Boot Manager doesn’t need much tweaking, but it does need to know what volume to boot from and how many seconds to wait for a user to choose an OS option. These options will work fine:
bcdedit /set {bootmgr} device boot
bcdedit /timeout 30
Next, create the OS entry object that will tell the Boot Manager to boot Windows from files in the \Windows folder on one of the system’s volumes. That volume is usually C, but if you’re booted from Windows Preinstallation Environment (WinPE), double-check which drive has the \Windows folder on it—WinPE might see it as D or E. (That’ll be important in a minute.)
Now, create the OS entry object:
bcdedit /create /d "Windows 7" /application osloader
The /create option (without an ID) and the /application osloader option tell Windows that you’re creating an OS entry for a Vista-and-later version of Windows. (The /d option contains the label that Boot Manager shows when offering multiple OS entries.) That returns a new GUID that you should plug into this next command:
bcdedit /default {<GUID>}
At this point, you’ve got a naked object that needs some values with the Bcdedit /set command that I introduced in earlier Bcdedit columns, but what to set those values to? Simple! Look at the output of Bcdedit on a healthy copy of Windows, and use it as a model. In my case, the \Windows folder is on drive D, so I entered these:
bcdedit /set {default} device partition=d:
bcdedit /set {default} path \windows\system32\boot\winload.exe
bcdedit /set {default} osdevice partition=d: bcdedit /set {default} systemroot \Windows
bcdedit /set {default} detecthal yes
Finally, add this command, or Windows won’t see the OS entry properly:
bcdedit /displayorder {default} /addlast
Give this a try with a test machine or two, and you’ll be Doctor Boot in no time!
Discuss this Article1
jonnyhz
on Feb 4, 2014
"The 100 MB System Reserved partition is used for the Boot Manager code, BCD (Boot Configuration Database), System Recovery Options (Windows RE), and start up files for BitLocker (if turned on).
If you want to have the 100 MB System Reserved partition in addition to the Windows 7 C: partition on a HDD or SSD after installation, then you would need to make sure that all partitions on the drive have been deleted until it is only unallocated space. Next, select the unallocated drive to install Windows 7 on. If there are no partitions on the disk, you will get the 100 MB System Reserved.
If you do not want to have the 100 MB System Reserved partition and only the Windows 7 C: partition on a HDD or SSD after installation, then select a formatted partition or drive to install Windows 7 on. If there are any partitions on the disk, you won't get the 100 MB System Reserved."
so, if you install windows to an EMPTY drive (unallocated space), a system partition (100 Mb) will be created, containing BCD info.... is this a precaution, a precursor to windows 7's "bcd in boot" configuration (illustrated above), or the non-virtualized way of doing things?
I'm still trying to go native vhd on barebones, having suffered a boot failure with my win7 vhd.... trying to understand what to do following the 'clean disk' operation
Originally scott's guide seemed logical, but having suffered boot issues, I want to protect myself from a repeat, and ideal avoid an windows/software reinstall (this is the land of V-OS after all!!)!
Learn more from "BcdeditBasics."
Anyone who uses Windows Server 2008 or Windows Vista knows that these latest Windows versions have brought some significant changes to Microsoft's OSs. One of these changes is the way you control Windows' boot loader, the software that supports storing more than one OS on a drive and that lets you configure the way Windows boots. With this change comes a new tool—Bcdedit—that anyone who administers Server 2008 or Vista systems must master. (See also, "Booting Up with Bcdedit" and "Build a Bootable BCD from Scratch with Bcdedit").
Prior to Vista, we controlled boot order and boot options by modifying the boot.ini text file at the root of the C drive. To change the boot-loader behavior of pre-Vista systems, we needed nothing more complex than Notepad and the knowledge of how to un-set boot.ini's "read only" component. Now, Microsoft has replaced boot.ini with a binary file called BCD, which resides in a hidden/system folder called \boot on whatever drive you boot your system from. Bcdedit is the tool you'll use to control BCD.
Boot Alterations
The BCD boot-loader structure introduces some new terminology. Whereas a boot.ini file might have several sections that let you boot a particular OS with specific options, Bcdedit has boot entries. A new Server 2008 or Vista installation has just one boot entry, but if you add an OS—for example, if you install both Server 2008 and Vista on the same system, or if you have only one OS on your system but want the option to boot that OS with different startup or debugging settings—you'd have more than one boot entry. You can see your boot entries by opening an elevated command prompt and typing
bcdedit /v
The top section of the output that Figure 1 shows—labeled Windows Boot Manager—contains global information: which boot entry boots by default, how long users have to choose a non-default boot entry, and so on.
Below that, Bcdedit displays two boot entries labeled Windows Boot Loader. The first boots a copy of Server 2008 (as you can see in the description line), and the second boots Vista.
Notice that Bcdedit /v shows a lot of long hexadecimal strings enclosed in brackets—items that you probably recognize as globally unique identifiers (GUIDs). You can safely ignore most of these GUIDs, but pay special attention to the first one in each boot entry, labeled identifier. You need these GUIDs when you inform Bcdedit which boot entry to make the default, what order to display the boot entries, which boot entries to copy, and so on. If you're like me, you'll find yourself feeling thankful that you can mark text and put it into the clipboard.
To tell BCD which boot entry to load by default, you use the Bcdedit /default command. For example, to tell my system to boot the Server 2008 boot entry, I would type
bcdedit /default \{6443870f-3c0c-11dd-835a-c0389998b4ec\}
If you can't imagine typing or even copying those GUIDs, you'll be glad to know that Bcdedit recognizes two well-known GUIDs: The \{current\} value is the boot entry that the OS is currently running, and the \{default\} value is whatever boot entry BCD currently knows about.
If I were to delete the \Windows folder from my Server 2008 system's E drive, I would essentially uninstall Server 2008 from my system—but BCD wouldn't know that. So, every time I booted my system, I'd see a useless option to boot Server 2008. To configure BCD to no longer show the Server 2008 option, I could use the Bcdedit /delete command:
bcdedit /delete \{6443870f-3c0c-11dd-835a-c0389998b4ec\}
If you're thinking about trying some of these commands, I recommend creating an extra boot entry to play with. Believe me, you don't want to accidentally delete your main OS's boot entry! To make a copy of your boot entry for test purposes, you can use the Bcdedit /copy command:
bcdedit /copy \{current\} /d "Test entry"
Note that I've made use of the \{current\} well-known GUID and added the /d option (mandatory with the /copy switch), which let me give the option a name for the new OS boot entry.
Whenever I set up a Windows NT 3.1 or later system, I find boot.ini's default 30-second wait to be excessive, unacceptably slowing down my boot times. So, I always like to modify the "timeout=30" value to 5 seconds. To do the equivalent in Bcdedit, I type
bcdedit /timeout 5
Familiarize Yourself
I miss boot.ini's simplicity, but BCD and Bcdedit are here to stay, so I recommend spending a little time getting familiar with Bcdedit. I'll cover more in-depth options next time.