Vista's MBR Disk Signature
The location and purpose of the Disk Signature.
There is something different about the Vista boot process and the way it uses a drive ID number in the Master Boot Record of the hard drive. This ID number has been around since NT 3.5 and is sometimes called the Fault Tolerance Signature but is now generally referred to by Microsoft as the Disk Signature. In previous NT operating systems the integrity of the disk signature was in most situations not crucial for ntldr to initiate the Windows boot process. With Vista on the other hand, if the signature has changed or can’t be found then the successor of ntldr, bootmgr, will halt before Windows is started with the error winload.exe..... is missing or corrupt. It is an inaccurate and misleading error message because winload.exe itself has not actually moved or changed. If I alter one digit of the signature then it's a winload.exe error, if I change it back again then Vista boots as before. (In Windows 7 the error message is now “The boot selection failed because a required device is inaccessible.” see winload.exe.....is no longer missing). A broader examination of the XP MBR and signature can be found on this page by Daniel B. Sedory. Update: Aug-2009 Vista MBR and VBR pages.
The original purpose of the disk signature was I believe mainly to allow the operating system to identify individual hard drives in a “Fault Tolerant” Dynamic Disk software raid configuration. It still has this use and others, but they are all mostly to do with the booting or booted OS being able to uniquely identify individual hard drives. Only on rare occasions and sometimes with scsi hard drives will it be used in the boot.ini file and so become essential for beginning the boot process. With IDE and SATA basic disk hard drives its main function has been to help Windows NT keep track of drive letter assignments. It still has this important use in Vista, but now it has a new significance that is vital to beginning the Vista boot sequence.
The Vista MBR
To boot an operating system the bootloader has to first be found and then started. In Vista finding the bootloader is the job of bootmgr with the help of the BCD store to tell it where to look. (In previous WinNT it is slightly different because ntldr is both bootmanager and bootloader and so it is the location of the main OS system files that ntldr has to find). Both ntldr and bootmgr have to first identify which hard drive they should look on. The ntldr does this with the aid of the boot.ini file, which lists the hard drives by number in the same order as the computer's BIOS sees them. The ntldr consults the boot.ini for the number of the drive that it wants and then checks the BIOS to find the location of that drive. In Vista the BCD store does not list hard drives by number at all but rather by their unique disk signature. When bootmgr queries the BCD for the drive it wants it is told the disk signature of that drive, so it then scans the connected drives till it finds the one with that signature. If no match is found then bootmgr cannot continue to look for the Vista bootloader (winload.exe) and hence displays the error message that winload.exe......is missing or corrupt.
So the disk signature is now a vital component in the boot process and has to be maintained for bootmgr to do its job. If a signature is changed then every boot option in the BCD for the affected hard drive will need to be updated to contain the new signature. If a signature is completely zeroed-out then a new one will have to be written and the BCD again informed. There are not many situations where the average PC user would ever do anything that could alter or damage the disk signature, so the whole process should remain transparent and trouble free. However, any imaging or cloning, installing OSes or dual and multibooting, could result in problems. Installing a bootmanager like XOSL that changes the disk signature, or updating the MBR with fdisk/mbr which zeros out the signature, would have obvious consequences. You can find an updated article on this topic here:- The Windows Hard Drive Disk Signature.
In addition to the disk signature the BCD also holds details about the location of partitions on a hard drive, which is also used by bootmgr to find the whereabouts of winload.exe. If a partition's starting point on a drive (its offset) has moved, then bootmgr will not be able to find the partition and again will not be able to locate winload.exe. This is covered in more detail on the Vista's Boot Files page. How to fix the BCD to cure a winload.exe error is dealt with on the cloning page.
The purpose of the extra code was not made clear but it seems it is mostly to do with the BitLocker drive encryption system. This MS white paper asking computer suppliers not to hook their recovery systems into the MS bootcode gives some insight. I have replaced the Vista bootcode in the MBR with that of XP, Win98, Linux's Grub and with that of four other MBR bootmanagers, in all cases Vista continues to boot just fine. This suggests that the extra code is not an essential part of the IPL and just as in previous Windows versions it remains OS-Independent, at least when a Trusted Platform Module and BitLocker are not being used.
Windows NT operating systems will remember the drive letters that have previously been assigned to partitions and drives. This differs from Win9x where drive letters are assigned on every bootup in a default order as the partitions and drives are discovered, which means changes to partitions or the adding of drives can cause letters to change. With NT the current hard drive partition drive letters can be maintained by linking them to a partition by using a unique number that is assigned to each partition and stored in the Windows registry. This unique partition number is generated from the disk signature of the hard drive and the partition offset. On Windows bootup the partition number is compared with the disk signature and if they match then the partition will be assigned the same drive letter that had previously been allocated to it.
If a disk signature is changed then Windows unique partition numbers become invalid. They no longer match the MBR disk signature and therefore drive letter assignments are lost. On first reboot after a signature change each partition on the affected drive will have its unique number recreated to match the new disk signature, then be reassigned a drive letter. These reassigned letters may not match the originals and so your drive letters may change. (You will also be informed that your new device/s have been installed and a reboot is required).
When you are using the Windows built-in bootmanager to dual or multiboot it is vital to maintain drive letters because Windows might not see itself as the default C: drive. If you have a Windows install that considers itself to be say the E: drive and a disk signature change causes this assignment to be lost, then during early bootup Windows will reassign drive letters in the default order, which will be the System partition as C: and the Boot partition as D:, which means later in the boot process the registry paths such as E:/Windows and E:/Documents and Settings, will be invalid. Windows 2K and XP cannot recover from such a drive letter change, but Vista seems to be a bit more adaptable and will struggle to the desktop, from where it is possible to edit the registry to restore the required drive letters, (see Drive Letter Problems). Be aware that with Vista it is possible when using the Microsoft bootmanager to have the Vista install see itself as the C: drive even when it is in fact a Boot partition to a different System partition. In this situation a drive letter re-ordering event caused by a signature change will assign the default D: letter to the Boot partition, causing the aforementioned problems. (There is an updated to this topic here.)
Multiple-path software may cause disk signature to change
A disk signature is unexpectedly changed on a Windows Server 2003 clustered physical disk resource
Best practices for using dynamic disks on Windows 2000-based computers
Recovering from an Event ID 1034 on a server cluster
Event ID 1034 for MSCS Shared Disk After Disk Replacement
How to replace a disk that is on a Windows 2000 or a Windows 2003 server cluster
How to use the Disk Management Snap-in to manage Basic and Dynamic Disks in Windows Server 2003
Disk Administrator Corrupts Partitions
Secure Startup - Full Volume Encryption: Technical Overview
The Windows NT 6 boot process
The different kinds of bootstrap programs
The following links are also within the text above:
Windows May Use Signature() Syntax in the Boot.ini File
Unable to log on if the boot partition drive letter has changed
How to restore the system/boot drive letter in Windows
How Windows 2000 Assigns, Reserves, and Stores Drive Letters
Order in Which MS-DOS and Windows Assign Drive Letters
An Examination of the Windows 2000 and Windows XP MBR.
Basic Storage Versus Dynamic Storage in Windows XP
Windows BitLocker Drive Encryption
Trusted Platform Module Services in Windows Vista
Custom Bootstrap Actions in Windows Vista