IPv6 and Network Properties

BOOT.INI Is Gone, BCD Is Here

Now and then, I need to edit the boot.ini file in order to fix some configuration issue. Ever since NT 3.1, it's been an ASCII text file on the hard disk.

With Vista, that's all changed; it maintains a boot file called the Boot Configuration Data or BCD located on the boot volume (that is, the volume that the operating system boots from, no matter what Microsoft calls it) in a folder named BOOT. It's one of those files locked open by the operating system (like the *.EVT event log files), so you can't edit it in the normal manner, and because that means that it'll be tougher for the odd bit of malware to modify it.

Don't go looking to edit it from the Control Panel, either; the Startup and Recovery dialog box is still in Control Panel hidden a few layers down, but where the XP version of that dialog had a button labeled "To edit the startup options manually, press Edit," that doesn't exist in Vista anymore. Instead, there's bcdedit.exe, a command-line tool for messing with Vista boot options.

BOOT.INI Review

The reason why I needed to modify boot.ini-normally a few-minute operation that became a multi-hour process, although it'll take you much less time after reading this-is that when I'm running test machines that are not connected to the Internet, either virtual or real, I'm often using slower machines, and in an effort to reduce my waiting time when playing with Vista, I like to turn off Data Execution Prevention (DEP). I do not recommend doing this on a production machine or, for that matter, any system into which you will type any data that you wouldn't want the world to know. But for test systems that you won't be sharing your vital data with, it's a great idea. With XP and 2003 systems, I could always shut off DEP by editing the boot.ini and adding the /NoExecute=AlwaysOff option to any boot.ini entry. But how to do that (and other things) to BCD? Well, to learn that, we've got to learn BCD-ese. Here's the boot.ini on my XP workstation:

 [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(2)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP x64 " /fastdetect / NoExecute=OptOut multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP x64 w/debug" /fastdetect / NoExecute=OptOut /DEBUG multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect 

This particular boot.ini offers three different operating system options when booting this computer; those three options are in the section named [operating systems]. The three lines following it (each is long and broken on the page, but there would indeed be just three lines if we were viewing this on a wide computer screen) is called a "boot.ini entry." For example, consider this one:

 multi(0)disk(0)rdisk(0)partition(2)\WINDOWS="XP x64 " /fastdetect / NoExecute=OptOut 

The multi(0)disk(0)partition(2)\WINDOWS is just an arcane way of saying "the actual operating system is on the second partition of the first hard disk, and in the Windows directory on that partition." That's followed by two "switches," /fastdetect (which tells Windows not to bother looking around for devices attached to parallel and serial devices, which hasn't been generally necessary since 2000 came out), and /NoExecute=OptOut, which is the normal setting for DEP. Because there are three operating system entries, I see a boot.ini menu offering those three every time I boot my workstation. Other useful switches are /maxmem, which tell your copy of Windows to not use your system's RAM above some level, or /debug, which enables system debugging, or /numprocs, which tells your system to ignore some number of processors.

Above the [operating systems] section, there is a [boot loader] section. It specifies two things: how long to leave the menu on the screen, and which option to make default if the boot.ini options time out.

Now, if you're scratching your head saying, "I never see anything like that boot.ini file, or a boot-time menu at all in either XP or in Vista," that means that you've got only one operating system entry. In that case, you don't get the menu on either XP or Vista. If you do have a Vista BCD with more than one entry, then you see a different boot menu from the one that you would have in the pre-Vista days, assuming that you had a multi-entry boot.ini. The Vista boot menu is text, but it's a bit snazzier than boot.ini, like the one that you see in Figure 1.1.

Figure 1.1: A Vista system with multiple boot options

This menu shows two options: "Microsoft Windows Vista," the option built when Vista's installed, and "Vista without DEP," an option that I've created and that I'll show you how to create. In addition to the operating system entries, Vista's Boot Manager also offers the option of booting straight to a memory tester-a convenient touch on Microsoft's part, particularly given that Vista systems typically need quite a bit more memory than XP systems.

BCD Terminology

To work with BCD, we need to learn a bit of BCD-ese. What we might think of as the entire BCD "database" is called the "store" or the "system BCD store." The store contains one or more "entries," which act as boot.ini entries did; thus, were I to translate my boot.ini into a BCD, I'd have a store containing three entries. There is, in addition to the entries, a tools menu that by default contains just one entry, the memory tester. Each entry may contain what we used to call boot.ini switches, like /NoExecute=AlwaysOff, but they're not called "switches," they're called "entry options."

Let's see how to relate this to an actual BCD by telling bcdedit to dump the current configuration. Do that by opening a command prompt as an administrator (right-click the Command Prompt icon, choose Run as administrator, and confirm the choice when UAC asks), and then type just bcdedit. I get an output like this (I've shortened a few items for clarity):

 C:\Users\mark>bcdedit Windows Boot Manager -------------------- identifier         {bootmgr} device             partition=D: description        Windows Boot Manager locale             en-US inherit            {globalsettings} default            {current} displayorder       {current}                    {} toolsdisplayorder  {memdiag} timeout            30 Windows Boot Loader ------------------- identifier         {current} device             partition=C: path               \Windows\system32\winload.exe description        Microsoft Windows Vista locale             en-US inherit            {bootloadersettings} osdevice           partition=C: systemroot         \Windows nx                 OptOut Windows Boot Loader ------------------- identifier         {} device             partition=C: path               \Windows\system32\winload.exe description        Vista without DEP locale             en-US inherit            {bootloadersettings} osdevice           partition=C: systemroot         \Windows nx                 AlwaysOff 

Notice that you see three sections in this report: a "Windows Boot Manager" section and two "Windows Boot Loader" sections. Remember the [boot loader] section? It has morphed into the Windows Boot Manager information. Each entry in the [operating systems] section gets its own Windows Boot Loader section.

Creating a Second OS Entry

Let's start putting bcdedit through its paces but…safety first! When installed, Vista creates one OS entry called "Microsoft Windows Vista." If you think that you'd like to play around with changing boot options then I highly recommend it, if for no other reason than to take advantage of my suggestion about speeding up test machines with that DEP configuration notion that I've already mentioned. But instead of mucking with the one boot entry that you've got, I even more highly recommend that you first make a second OS entry and do your experiments on that entry. After all, it is possible to make your system unable to boot with a bad OS entry, and that is guaranteed to ruin your whole day. (Unless you like watching Vista install. I mean, it does have that lovely "undersea view of the bottom of a kelp forest" background while installing.)

How to create a second OS entry? That's one of bcdedit's abilities. The easiest way to create a second OS entry is to just copy the existing one with the bcdedit /copy {ID-of-entry-to-copy-from} /d description command. I will explain {ID-of-entry-to-copy-from} in just a couple of paragraphs but for now we can use {default}, which is the identifier for the default operating system entry. Using that information, I originally created my "Vista without DEP" OS entry like this:

 bcdedit /copy {default} /d "Vista without DEP" 

When I did that, I got a response of

 The entry was successfully copied to {} 

I'm going to explain that thing in the curly braces-it's called a globally unique identifier or GUID-next, but before I do, let me just summarize where we are at this point. If you try that command on a Vista system and reboot, you will get to see the Windows Boot Manager and your new "Vista without DEP" entry that, at the moment, doesn't do anything different than the "Microsoft Windows Vista" entry. But now you've got a safe OS boot entry to play with.

Understanding Vista Boot Manager Identifiers

What's with those {default} and {} things? Windows Boot Manager needs some way to be able to identify the multiple operating system entries. Now, it could give them names like "default Vista OS entry," but that would be, um…okay, I don't know why they don't let you just give them arbitrary identifiers; it just seems to be something that's been in Windows since Windows 2000. The idea is, I suppose, that you might go crazy and accidentally create two OS entries with identifiers of "default Vista OS entry," and then your computer would implode. Anyway, when Vista creates a new OS entry, it also generates a random 128-bit number and uses that as the OS entry's "true name." Now, inside that OS entry is something called a "description" and you and I can fill it with text like "Vista without DEP" or the like, and you and I will use that to identify a particular OS entry, but Vista just sees that "Vista without DEP" name not as a real name, but instead as window dressing-{} is the true name for our new "Vista without DEP" OS entry as far as software's concerned.

That means that when you want bcdedit to do something to a particular OS entry, then you'll usually have to identify the entry that you want to configure. Usually that'll be the GUID of the OS entry. But you will sometimes be able to save a little work, as GUIDs aren't the only kind of OS entry identifier that bcdedit will take. It also recognizes the {default} and {current} identifiers. Note that they're surrounded by curly braces, as are the GUIDs. {default} is an identifier that tells bcdedit, "I want you to configure that OS entry that starts up by default, but I don't want to look up its GUID." {current} does the same thing, but it identifies the OS entry that the system is currently booted into. Thus, if you're working on a Vista system that booted into the default operating system entry, then both {default} and {current} point to that OS entry.

So, back a page or two, when I offered the command bcdedit /copy {default} …, I was telling bcdedit to copy whichever operating system entry was the one I'd get by default. When bcdedit spat back the big number in the curly braces, it was telling me that GUID of the OS entry that it had just created for me.

If you ever need to see the GUIDs of your computer's default OS entry, just type bcdedit /v and you'll get the same long listing as you saw a few pages back when I typed just "bcdedit," except that instead of seeing {current} on the Identifier line, you'll get the GUID of that entry. Both a GUID surrounded by curly braces or the predefined {current} or {default} items are called "identifiers" by bcdedit.

Choosing Timeout and Default OS with bcdedit

Now that we're experts on identifying OS entries, let's return to some nuts and bolts. As with boot.ini, Windows Boot Manager's main jobs are to define a timeout value and a default. (Clearly there are also other things that Windows Boot Manager does, but I'm trying to cover just the essentials here.)

Changing the Boot Manager Timeout

To change the timeout value, type bcdedit /timeout numberofseconds to set the number of seconds that Windows Boot Manager waits before choosing the default operating system entry. For example, to tell Windows Boot Manager to wait 15 seconds, you'd type

 bcdedit /timeout 15 

The adjustment you'll want to do more often is probably choosing the default operating system instance.

Changing the Default Boot Manager Entry

You'd think the second task-telling Boot Manager which OS entry to load by default-would be a snap. It is, almost; you can pick any OS entry and make it the default, but, as you'd probably guess by now, you've got to refer to that OS entry by an identifier, and the chances are good that you'll have to use its GUID.

As we've already seen, the new "Vista without DEP" OS entry on my system got a GUID of {}.

Warning 

Even if you type into your system exactly the same commands that I've typed, you will not get the same GUID, as they're random. So if your GUIDs look different than mine, don't panic, it's supposed to work out that way.

Using that GUID, I can then make that entry the default by typing bcdedit /default { guid }, so for example to make "Vista without DEP" the default, I'd type

 bcdedit /default {} 

Again, you can do something similar on your system; just remember that you'll have to retrieve the particular GUID of your "Vista without DEP" OS entry; simply typing bcdedit by itself will, recall, show you your OS entries and their GUIDs. And don't forget to surround the GUID with curly braces; bcdedit won't work without them. Then, after typing bcdedit all by itself a second time, I'll see the same output, except in the "identifier" line the {} will be replaced by {default}. The other OS entry, the "Microsoft Windows Vista" one, will have an identifier of {current}.

Changing an Entry Option

With our new OS entry created and set to the default, we're ready to start with playing with entry options. Recall that "entry option" is the bcdedit phrase for what we used to call "boot.ini switches." Some switches have values, like the /NoExecute=AlwaysOff example that I've already offered, and some, like /basevideo (which says to boot the system with the basic VGA driver) don't have values, and you enable them by including them in the OS entry and disable them by leaving them out. In BCD and bcdedit, however, every entry option has both a name, like NoExecute, and a value, like AlwaysOff. (Case seems not to matter to BCD and bcdedi t, in my experience.) Boot.ini switches that didn't previously have a value, like "/basevideo," now get a value of "yes" or "no." (/basevideo is now called simply "vga," by the way.)

You can include an entry option by typing bcdedit /set [{entry guid}]entry-option-name [entry-option-value]. To set nx to AlwaysOff in the currently running operating system entry, then, we could type

 bcdedit /set {current} nx AlwaysOff 

If, however, we hadn't included an OS entry at all, then bcdedit would have assumed that we wanted that change done on the currently booted OS entry anyway, and so this would get the same job done:

 bcdedit /set nx AlwaysOff 

To set nx in the default OS entry, we'd type

 bcdedit /set {default} nx AlwaysOff 

To tell the OS entry with a GUID of {} to boot using the standard VGA video driver, we could type

 bcdedit /set {} vga yes 

(Just to be clear, that command would be typed as one line.)

Now that you know how to modify boot options, here are a few of the available Vista boot options in BCD and, for the boot.ini black belts out there, the corresponding boot.ini switches of each option entry:

nx, as I've mentioned, controls DEP. Its boot.ini value was just /NoExecute. nx can be can be set to AlwaysOn, which applies DEP to all user applications and operating system programs; AlwaysOff, which does not apply DEP to anything; OptOut, which applies DEP to everything except particular programs that you exclude; or OptIn, which applies DEP to all operating system programs and any applications that you add in. (You can do the excluding or including in the Control Panel's System applet.)

vga is, as I've already explained, the setting telling your system to forgo whatever video driver it's currently using and instead use the generic VGA driver. It takes values "yes" or "no." Its boot.ini counterpart was /basevideo.

numproc, which lets you limit your OS to a certain number of processors, was also /numproc in boot.ini, and takes a number; bcdedit /set numproc 1 would tell your system to only run one processor on the currently running OS entry. This can be useful because once in a while, you'll run into an application that was only tested on single-processor systems but that contains bugs that only pop up in multiprocessor computers.

removememory lets you exclude some amount of memory from Vista. Its boot.ini counterpart was called /burnmemory. It takes a value in either decimal or hex (prefix a hex number with "0x" so it recognizes it as hex) of the exact number of bytes of memory to give Vista-specifying "500000" would remove about a half a megabyte of memory from Vista, not about a half a gigabyte!

truncatememory is another command restricting the amount of RAM that you allow Vista to use. Where removememory specifies how much RAM to take away from Vista, leaving it the rest, truncatememory specifies how much RAM to give to Vista, denying it the rest. You wouldn't use both of these in the same OS entry, by the way. As with removememory, truncatememory takes a number as a parameter. That number is, like removememory, the exact number of bytes to give Vista. Truncatememory's name in boot.ini was /maxmem.

If that's still not clear, imagine that you've got a system with 2 GB of RAM. removememory 500000000 would remove a half gig, leaving 1.5 GB of RAM for Vista. You could do the same thing with truncatememory, but you'd feed truncatememory 1500000000.

quietboot skips the GUI's little animated rectangles that ripple left-to-right as an indicator that the OS is loading. Set it to "yes" or "no." It was /noguiboot in boot.ini.

sos, which was named /sos in boot.ini, tells the operating system to show each driver and service's name as the operating system boots. This can be useful if your system locks up on boot; just sos to "yes" and reboot (clearly you need a different way to boot to make this setting, perhaps another OS entry!), and the name of the last driver loaded may be the culprit. This takes "yes" or "no" for parameters.

bootlog tells your system to create a log of the drivers that the OS loads, in the order in which it loads them. It then saves that log in Windows directory in a file called ntbtlog.txt. This option takes "yes" or "no" and was called /bootlog in boot.ini.

Cleaning Up: Deleting OS Entries

That's about all I wanted to cover in BCD and bcdedit to help you tweak your OS's starting parameters. But if you find that you've got your OS entry just the way you like it, and don't need the one automatically built by Vista, then you might want to tidy up a bit. You can delete an OS entry with the bcdedit /delete identifier command. For example, on my system, I'd first type "bcdedit" to find out the GUID of the now-unused OS entry, discover that it was {}, and type

 bcdedit /delete {}