Understanding MultiBooting
and Booting Windows from an Extended Partition

by Dan Goodell
Introduction Partitions The MBR Principles Tools Imaging Restoring Partition Table Win98 LBA Boot.ini Partition Sigs Boot Mgr Appendix
Fixing Windows 2000/XP Drive Letters

Windows NT, 2000, and XP remember drive letters previously assigned to partitions. This can create problems when cloning, duplicating, or moving these OS's.

For example, suppose you have XP installed as C: in partition-1, and partition-2 has been formatted and designated D: by XP. These assignments will be recorded in the registry. If you subsequently clone XP-1 to partition-2, of course the registry goes with it. The new copy of XP is supposed to be a clone of XP-1, so is supposed to see partition-2 as C:. But when XP-2 boots, its registry recognizes the partition it's on was previously designated D:, and keeps that letter (and partition-1 keeps the letter C:). But the letter C: is embedded in countless XP-2 registry entries and configuration files, so when XP-2 starts drawing information from partition-1, you end up with a "schizophrenic" system, with XP-2 confusing which partition it's supposed to using.

Here's another example of a common cloning mistake: suppose XP-1 is C: on disk-1, and F: is a partition on disk-2. Then XP-1 is subsequently cloned to XP-2 on disk-2, and disk-1 is removed. Again, XP-2 will recognize its partition was previously given a drive letter and will keep it. The boot process may hang (usually at the login or blue "Welcome" screen) while XP-2 searches in vain for "drive C:".

The above examples concerned a destination partition that had already been assigned an undesirable letter, but you can run into trouble even if no drive letter had been previously assigned. If partition-2 did not have a previous drive letter, XP-2 will discover partition-2 the first time it boots and will assign a new drive letter. But if the previous C: partition still exists, it will keep that letter and partition-2 will have to get something else. (This is true whether or not you try to hide partition-1. Remember, common techniques for hiding a partition don't make it invisible--Windows will still know some kind of partition is there, and if it had previously been assigned a drive letter, it will keep that.)

These examples illustrate two general rules for successful cloning of NT-family OS's: Although these examples use XP, they apply just as well to NT and 2000.

How does Windows XP remember drive letters?

Windows NT, 2000 and XP keep a list of partitions, identifying each by a signature. The list is maintained in the registry key [HKEY_LOCAL_MACHINE\System\MountedDevices]. Drive letters are also recorded in this registry key and matched to the corresponding partition signatures. In this way, the OS can remember the drive letters assigned to each partition from one boot to the next. Win2000 records the signature of every partition in the registry, even those it cannot read (such as linux partitions). In contrast, XP only records "visible" partitions, so hidden and linux partitions are not listed in the XP registry.

The partition signature is derived from the DiskID and the partition's starting sector number. The DiskID (sometimes called the "NT serial number") is a group of four bytes in the master boot sector (LBA 0) at location 01B8h. Each partition's starting sector number is doubled and combined with the DiskID to form a unique signature for that partition. For example, consider a disk with the serial number 3D173D16h (hexadecimal) and a partition starting at LBA 44933868 (decimal). Double the sector number (89867736) and convert to hexadecimal (055B45D8h). If this partition were designated E:, the corresponding registry values would be:
     \??\Volume{...} = 16 3d 17 3d 00 d8 45 5b 05 00 00 00  
     \DosDevices\E:  = 16 3d 17 3d 00 d8 45 5b 05 00 00 00  
(Programmers will note the "little-endian" nature, in which the bytes are stored in reverse order.)

Purists may wish to know the signature appears actually to be derived from the partition's starting byte number rather than starting sector number. Sectors universally contain 512 bytes, so LBA 44933868 starts with byte 23006140416, or 055B45D800h in hexadecimal terms. Mathematically, we arrive at the same result by doubling the sector number and offsetting the result by 100h--hence the 00 byte between the DiskID and sector location in the example above. Since we work in sector units with ptedit, I find it easier to work from the starting sector instead of starting byte number.

Every time Windows boots it calculates signatures for all partitions and adds any new signatures to the [MountedDevices] registry key. If the partition's file system is recognizable to Windows (i.e., unhidden FAT/FAT32 or NTFS), a drive letter is also assigned. Drive letters previously assigned are remembered and skipped when Windows assigns letters to newly discovered partitions. The 2000/XP sequence of assigning new drive letters follows the same manner as done by DOS and Win95/98/ME.

Note that if a partition no longer exists in the system, any drive letter previously assigned to that partition may be available for reallocation to new partitions. "No longer exists" means the partition tables no longer show any partition beginning at the same sector location. Remember that hiding a partition doesn't make it invisible, but really just disguises it. That means that using a boot or partition manager to hide a partition won't necessarily result in Windows forgetting that partition had previously been assigned a drive letter, whether or not XP can access files on it.

2000/XP's Disk Management snap-in permits the user to change the drive letters assigned to each partition, with the exception that a boot or system partition cannot be changed. Thus, it's easy to rearrange drive letters of data partitions by using built-in 2000/XP tools, but other methods are needed to manipulate drive letters of the boot/system partition(s).

How to Manage System and Boot Drive Letters

When moving or cloning 2000/XP, you may need to control the drive letter assignments remembered in the registry. It is vital that the new copy see itself by the same drive letter as the original. There are three basic approaches you can take:
  1. directly edit the assignments in the clone's registry (difficult);
    - or -
  2. delete the previous assignments so they are not remembered (easier);
    - or -
  3. force XP to think the previous assignments are invalid (easiest).
The latter two are relatively easy, but leave it to Windows to assign new drive letters the first time the clone boots. Therefore, these methods only work if the new drive letter 2000/XP assigns to itself will be the same as the original system had used. In practice, this is easy to recreate if Windows is supposed to be C:, but difficult for any other drive letter.

Method #1:
One way to correct an erroneous drive letter is to directly edit the [MountedDevices] registry key. Microsoft provides instructions how to do this, but that only works if you can still boot into Windows. If Windows won't boot, you need a method that works from outside Windows.

In that case, use Savepart, a freeware program. This utility's main function is imaging and restoring partitions (like Ghost, DriveImage, et al), but one of its extra features is the ability to deliberately specify drive letters in the 2000/XP registry. Start Savepart, point to the clone's partition, and tell it what drive letter you want that partition to be assigned when it boots.

The following two methods are actually easier if you want the partition to be designated C:, but if the original partition was not designated C:, then Savepart should be able to set the correct drive letter.

Method #2:
If you plan ahead, you can clear the registry's drive letter table before cloning the partition, then let 2000/XP rebuild it the next time it boots. To clear the table of partitions and drive letter assignments, use regedit to navigate to [HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices]. This key will contain a bunch of values like "\??\Volume{...}" and "\DosDevices\C:", etc. (See illustration above.) Deleting all values will force Windows to regenerate all signatures and assign fresh drive letters the next time it boots. Thus, you first clear the registry values, make the clone, and then the clone will rebuild the table the first time it boots.

(Technically, you only need to clear the [MountedDevices] entries related to the drive letters you want the registry to forget, but if you're not confident you can identify the exact entries, there is no harm in deleting all entries. At worst, you would just need to use the DiskMgmt snap-in to reset your custom drive letters for other devices such as CD drives, etc.)

Method #3 ("Kawecki's Trick"):
If the clone has already been made and you don't want to start over (using Method #2 and recloning), you can fool Windows into thinking the previously assigned drive letters belong to partitions that no longer exist. Drive letters are remembered by partition signature, so by invalidating the previous signatures you can induce 2000/XP into releasing previously used drive letters for reassignment.

One way of doing this is to delete or alter the DiskID in the MBR. Since the DiskID is part of the partition signatures, this forces a change in the signatures and previously remembered drive letters can be reassigned because they no longer match valid partition signatures. The easiest way to delete the DiskID is to use a Win98 boot floppy (aka, "Windows 98 Startup Disk"). Boot the computer from the boot floppy, run the command "fdisk /mbr", remove the floppy, and reboot into 2000/XP.

The Win98 fdisk /mbr command is similar to the 2000/XP fixmbr command (used from the 2000/XP recovery console). The intended purpose of both commands is to restore the MBR boot code, and both commands do replace the boot code without altering the partition table at the end of the master boot sector. The two commands are not exactly identical, however. As detailed by Michal Kawecki, the NT/2000/XP boot code is 440 bytes, while the Win98 boot code is 446 bytes (271 bytes of executable code, 80 bytes in error messages, and 95 bytes filled with zeroes). The NT/2000/XP fixmbr command replaces the MBR boot code but stops short of overwriting the four bytes of the DiskID that sits between the boot code and the partition table. The Win98 fdisk /mbr command will replace the boot code and zero the DiskID--albeit, unintentionally. As Kawecki points out, we can take advantage of that "mistake" because it has the effect of invalidating the partition signatures--since the signature is derived from the DiskID and Windows has to regenerate a new DiskID, it has to recalculate the signatures and assign new drive letters, abandoning any previous assignments.

author: Dan Goodell, ©2004-2005