This month, I want to take a final look at Bcdedit, the Windows Vista (and later) tool that lets you modify your system's boot configuration data (BCD) database, which replaces pre-Vista systems’ boot.ini file. Specifically, I'd like to share a couple of instances in which I've used Bcdedit as a troubleshooting and system-recovery tool and come away with valuable tips that are applicable in any environment.
Tip #1: Make a Bootable WinPE CD or USB Stick
At a conference, a friend came running up to me, looking a bit panicked. After he explained what he'd done, I understood why. He was running Vista on his laptop, and he'd just read about all the cool things that Bcdedit can do, so he decided to try the command on his system. You guessed it: An error in his Bcdedit typing had left his system in a non-bootable state. He’d grabbed me because he'd read about Bcdedit in my book Administering Windows Vista Security.
Puzzled, I asked, "Didn't you first create a copy of the working Bcdedit OS entry, as I instructed on page 12?" Sheepishly, he admitted that he hadn't, so he couldn't boot his system. In my testing, I’d never painted myself into this particular corner, so that meant I didn't have a close-to-hand solution—but then I remembered that I had a bootable Windows Preinstallation Environment (WinPE) CD in my laptop bag.
Figuring we couldn't make things any worse, we booted up his laptop from the CD, typed in the Bcdedit command, and lo and behold, the BCD database appeared on his hard disk. A quick Bcdedit /deletevalue command undid his goof, and the system rebooted like a charm. To learn about making a bootable WinPE CD, check out “Walkthrough: Create a Bootable Windows PE RAM Disk on CD-ROM” (technet.microsoft.com/en-us/library/cc749311.aspx?ppud=4).
Tip #2: Use Truncatememory to Smoke Out a Bad Memory Location
I was on the road again, in my hotel room bright and early, when I fired up my laptop and faced a blue screen. Now, I'd seen this blue-screen warning before: The system was attempting to load the OS into bad memory. I also knew the simple procedure that solves this problem most of the time: Open the computer’s casing, remove the RAM, and re-set it. Just one problem: I'd rearranged my travel bag and neglected to bring my just-short-enough-to-get-past-airport-security Phillips screwdriver, so I couldn't get into the computer to remove the small-outline dual-inline memory modules (SO DIMMs).
That's when I remembered that boot.ini used to let me instruct my computer to boot Windows XP but ignore any RAM past a certain memory address. That capability would be useful, I reasoned, because my laptop has 8GB of RAM, and Vista can run in 512MB if necessary. If I got lucky, the troublesome memory address would be above 512MB, and I could simply instruct Vista not to use any of the memory above 512MB. I booted up my laptop with that WinPE CD, and all was well (pretty much proving that the bottom 512MB was fine). As I showed you in "Bcdedit Basics" (InstantDoc ID 101168) and "Booting Up with Bcdedit" (InstantDoc ID 101362), I could use WinPE's Bcdedit to control the way my copy of Vista would boot, and I could use the Bcdedit /v command to obtain the GUID of the OS entry identifying my system's default boot configuration (i.e., {5605e930-fb47-11dc-88fe-d235397e182d}). That information let me build this command:
bcdedit /set {5605e930-fb47-11dc-88fe-d235397e182d} truncatememory 536870912
On the OS entry identified by the {5605e930-fb47-11dc-88fe-d235397e182d} GUID, Bcdedit would now boot the system with the restriction that it can’t see any RAM above the 536,870,912th byte.
If this worked, I would demonstrate that the RAM plugged into the first half-gigabyte of physical addresses was trouble-free. It
did work, so I felt bold enough try a few larger values, and I quickly found that I was OK for roughly the first 2.5GB. (Those binary searches I learned about many years ago sure paid off!) I got the presentation done, borrowed a screwdriver from a helpful audience member, and was up and running at 8GB in no time.
Bonus Tip: Software Testing
I should note another great use for Bcdedit’s Truncatememory switch: software testing. Have you ever found yourself in a situation in which you need to test an app before you let it loose in your environment? Sure, you have. But what if you have 4GB of RAM on your desktop, and the average user has 1GB? You
could start pulling out RAM chips to ensure proper testing—or you could just put Truncatememory to good use.