The Desktop FilesDual Booting with Windows XP and Windows PE 2.0

Wes Miller

Download the code for this article: Desktop2008_02.exe (151KB)

In previous installments of The Desktop Files, I've mentioned that Windows PE has become a tool for recovery, and I've explained how you can use it from a second partition. An inquiry I received recently has made me think that it might be worth discussing a new spin on this—using Windows PE 2.0 and Windows XP together.

After all, many of you may be using Windows® XP for some time, and Windows PE 2.0 is the version Microsoft is supporting going forward (note that there will be no further updates to Windows PE 1.x).

One important difference between Windows PE 1.x and 2.x is that Windows PE 2.x can boot via a standard boot interface (versus the specialized method that Windows PE 1.x uses). While you can boot Windows PE 1.x or 2.x from a second partition, the convenience of booting it on the same boot partition as your operating system is installed on has lots of potential, which I'll discuss shortly.

Two Boots for Windows

Windows NT® has always been relatively tolerant of dual booting. But as Extensible Firmware Interface (EFI)-based computers have begun to replace the old IBM PC AT BIOS, Microsoft has changed the Windows boot mechanism to work more optimally with EFI and to have one boot mechanism across all architectures. The new boot mechanism for Windows, beginning with Windows Vista®, is referred to as the Boot Configuration Database, or BCD (see microsoft.com/whdc/system/platform/firmware/bcd.mspx). But whether you are talking about the old boot.ini or the new BCD mechanism, Windows can generally boot other operating systems, even if it means handing off the boot process to another boot loader.

Before we start, it is critical that you remember that Windows PE 2.0 only works on systems that have both full Advanced Configuration and Power Interface (ACPI) compatibility and 384MB (ideally 512MB) of RAM. As I noted in my May column (technetmagazine.com/issues/2007/05/DesktopFiles), non-ACPI systems will fail to boot Windows PE 2.0, and, because Windows PE 2.0 must boot to a RAMDisk, it needs to have enough RAM to hold the RAMDisk, any scratch space, and all RAM working set. If your system has less than 384MB of RAM, don't even consider this route; use Windows PE 1.6 instead. Even a hand skilled at reducing Windows PE size cannot make it run well on 256MB.

Oh, the Problems You'll Solve

Now let's take a look at the problems you might tackle by booting Windows PE 2.0 from the same partition as Windows XP.

Full-System Recovery This is just one task made possible by booting Windows PE right from the Windows XP partition. Since Windows PE 2.0 (as Windows PE 1.6 before it) can boot entirely into a RAMDisk, you can reimage the entire disk—or use ImageX to restore the Windows XP files by themselves, since it's not necessary to reimage the entire partition.

By allowing users to boot to Windows PE at startup, they can recover their own systems even while working remotely. The image could come from a secondary partition, a network share (if the users won't be mobile), a recovery DVD or USB hard disk, or, if you are using ImageX, you could even store it on the partition being recovered. This sort of on-disk recovery is a great solution for many problems (with the exception of physical disk corruption). It's obviously not great at restoring user data unless that data is protected in the first place and then restored as a part of the recovery. Remember, you should be using roaming profiles and backing up data from the PC to prevent that kind of loss. You should also ensure that any recovery mechanism you use can mitigate any potential data loss on behalf of the user (including loss due to EFS encryption keys being reset).

File Recovery Windows PE also provides the mechanism to get a system up and running even if the primary installation of Windows will not boot. In that case, you are able to boot and recover user data either to another system (provided you have warm backup systems available for users) or to another location so that the user may begin working again soon.

System Repair Finally, booting Windows PE on Windows XP lets you repair a system by running either a set of troubleshooting scripts or a simple user-driven repair or recovery application. The process is similar to full system recovery, but it will be narrower in scope (and won't risk user data).

Now that you have some idea of what you can do if you boot Windows PE on the Windows XP partition, let's see what is going on behind the scenes so you can apply the process to any solution you like.

Before Windows Vista

Before the advent of Windows Vista, here's how BIOS/Master Boot Record (MBR)-based systems booted. The BIOS pointed to the boot device (in the case of the hard disk, it points to the MBR on the disk). The MBR executed code that specified which partition to boot. Note that this is the first partition that has the active flag set for it. In the earliest versions of diskpart, you couldn't make a partition inactive (that is, you couldn't remove the active flag). The switch was added to diskpart to fix this—otherwise it would be the first partition in partition table order that had its active flag set. The partition contains the boot sector—which tells it which code to execute next. From Windows NT to Windows Server® 2003, the code to run is in a file named ntldr, with no file extension. If you've ever formatted a disk, didn't install Windows, and then attempted to boot, you've seen the "NTLDR not found" error message.

You'll be interested to know that ntldr is fully backward-compatible—but of course it's not forward-compatible. This means that Windows XPs ntldr can boot Windows 2000, but not vice versa. This is why it's always important to install the oldest operating system first if you plan to dual boot. Since ntldr doesn't have version numbering attached to it, it's even more important to keep this straight.

Ntldr is a real-mode (16-bit) app that launches NTDetect.com, which performs basic device detection and then launches the kernel, ntoskrnl.exe (this may be one of several files—always renamed to be ntoskrnl.exe). The kernel is the critical component in the Windows boot process.

This summary of the boot process is somewhat simplistic, and I've omitted the entire initialization of Win32®, but that's not pertinent to this discussion. If you want more information about it, I recommend you read Windows Internals, Fourth Edition by Mark Russinovich and David Solomon (Microsoft Press®, 2004).

Another thing to note is that when you boot from CD, Windows Setup and Windows PE run setupldr.bin instead of ntldr. This file actually contains slightly different boot code so that it can boot from CD (which ntldr cannot). This is why in order to boot Windows PE 1.x, you renamed setupldr.bin to ntldr and put it on disk. It's also why that file couldn't then load a boot.ini file (because setupldr.bin was designed just for CD booting, and, as a result, boot.ini wasn't expected to be necessary).

Windows Vista and Beyond

Windows Vista changed many pieces of this process. Windows Server 2008 changes it further by enabling IA32 (32-bit support) for booting from EFI—something that hasn't been possible to date outside of Itanium-based systems. For BIOS-based systems, the initial steps of the boot process are largely unchanged. The key difference is that BOOTMGR is the boot loader that is initialized and then performs the following steps.

It looks in the boot directory for the BCD file, which is effectively its own registry hive. The BCD contains the boot entries (including the default) to boot. See Figure 1 for image types (executable file types), and see Figure 2 for the specific application types to launch. One (or more) of these entries can be a reference to ntldr. Only one of them can actually reference the well-known GUID used to load ntldr (see the fifth row of Figure 3). The bootmgr then decides which entry to load next, depending on whether the system is being booted, has been hibernating, or is booting to ntldr or another boot manager (in which case it would point to another boot sector and launch that loader). This would be most common if you were dual booting with a non-Windows operating system. You can find more information at microsoft.com/whdc/system/platform/firmware/bcd.mspx.

Figure 3 Standard application objects

Figure 2 Application types

Figure 1 Image types

You'll notice that the Windows Vista revamped boot infrastructure is much more organized than previous versions—outside of the bootmgr, all of the boot code exists within the root-level \boot directory and is handed off to Windows-specific binaries once BCD has specified to do so.

Booting Windows XP and Windows PE 2.0

You can probably start to see now how Windows PE, using the Windows Vista boot manager, can act as an intermediary that allows you to continue to boot Windows XP or earlier versions of Windows while adding Windows PE 2.0 to the mix for an integrated recovery tool.

Of course, you are going to be adding another step to the boot process, but it is a step that Microsoft designed. Knowing that the new bootmgr infrastructure needed to be backward-compatible with the existing ntldr and other third-party boot managers, bootmgr was intentionally built to support such solutions.

So now that we've examined how Windows boots and how the new BCD works, how do we tie the two together and get Windows PE 2.0 down on our existing Windows XP installation? There are two ways to put down the Windows Vista boot sector—the piece of boot code that tells the system to start bootmgr. One of them is to use diskpart and create and format a new partition with Windows PE 2.0. But that's not going to be an option here, since you've already got an existing Windows XP installation that you don't want to damage or move. Instead, follow this process:

1. Ensure you have a copy of bootsect.exe and bcdedit.exe on your Windows PE 2.0 boot CD (they can both be found on your Windows Vista installation DVD).
2. Boot your Windows XP system to the Windows PE 2.0 CD.
3. Once booted, run this command:

    bootsect.exe /NT60 ALL

This will set the boot sector to be the Windows Vista-compatible boot sector that knows how to launch bootmgr.

4. Copy the boot manager to the hard disk:

    xcopy BOOTMGR C:\BOOTMGR /I

5. Copy the boot.SDI file to the \BOOT directory on the hard disk. You'll need to make a copy of this before you boot, as it will be locked and unable to be copied while running Windows PE:

    xcopy BOOT.SDI C:\BOOT\ 

Correct the source path accordingly.

6. Copy the boot.WIM to the hard disk. Like the SDI, you should have a secondary copy available; you will not be able to copy the file you are running from:

    xcopy BOOT.WIM C:\BOOT\BOOT.WIM 

Correct the source path accordingly.

7. Now, create a new BCD store:

    bcdedit /createstore

8. Next, create the BCD entries to load Windows PE:

    bcdedit /create {ramdiskoptions} /d "Boot Windows PE"
    bcdedit /set {ramdiskoptions} ramdisksdidevice partition=c:
    bcdedit /set {ramdiskoptions} ramdisksdipath \boot\boot.sdi
    bcdedit /create /d "Windows PE" /application OSLOADER

9. The last line will return a GUID. Replace {YOURGUID} with the actual GUID that was returned. These are the entries to RAMDisk that boot Windows PE from your hard disk, shown in Figure 4.

Figure 4 Entries to RAMDisk that boot Windows PE from your hard disk

bcdedit /set {YOURGUID} device ramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} path \windows\system32\winload.exe
bcdedit /{YOURGUID} osdeviceramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} systemroot \windows
bcdedit /set{YOURGUID} winpe yes
bcdedit /set {YOURGUID} detecthal yes

10. Now, create bootmgr entries so Boot Manager will start:

    bcdedit /create {bootmgr} /d "Boot Manager"
    bcdedit /set {bootmgr} device boot

11. Finally, set up a BCD entry for your existing Windows installation (change the display text from Windows XP to whatever you would like to be displayed in the boot manager boot menu. The last command also sets it to be the first (default) entry in the boot menu:

    bcdedit /create {ntldr} /d "Windows XP"
    bcdedit /set {ntldr} device partition=C:
    bcdedit /set {ntldr} path \ntldr
    bcdedit /displayorder {ntldr} /addfirst

12. You should now be able to restart your system and have it launch either the previous installation of Windows or Windows PE 2.0 by selecting the appropriate boot menu entry. Figure 5 shows the sample output from bcdedit /enum all. This command lists all entries in the BCD after the entries have been added (this is from within Windows PE 1.6).

Sample input  (Click the image for a larger view)

I have been working on a script that can perform this task automatically. Currently it can only copy the boot files to the hard disk and set up your BCD entries. It cannot set the boot sector to be the new Windows Server 2008 value while running Windows —that has to be done offline, under Windows PE. You can find the script in the code downloads section of the TechNet Magazine Web site at technetmagazine.com. To run the script, you will want to have the following items in the same directory as the VBScript you are running:

1. BCDEdit
2. BOOTMGR
3. A \BOOT\ directory (from the Windows Vista or Windows PE 2.0 media)
4. A \SOURCES\ directory with a valid, bootable Windows PE 2.0 BOOT.WIM file

It will create the BCD and copy the appropriate boot files. After booting to Windows PE and running bootsect, you should be able to dual boot.

Undoing the Dual Boot

Undoing the dual boot is even easier than putting it in place. You just need to restore the boot sector to the pre-Windows Vista boot sector by running the following command:

bootsect.exe /NT52 ALL

Once it is restored, you can delete bootmgr and the \boot directory. On the next reboot, the boot sector will force ntldr to start instead and completely remove Windows PE 2.0 and all Windows Vista boot binaries from the boot flow.

Wes Miller is a Technical Product Manager at Initiate Systems (InitiateSystems.com) in Austin, Texas. Previously, he worked at Winternals Software and as a Program Manager for Microsoft. Wes can be reached at technet@getwired.com.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.