In the PC architecture, There are three constants regarding the MBR. First, the Boot program will be loaded and executed by the BIOS. The Boot Program must ensure that something is loaded into memory and executed when it is completed. Otherwise, the boot will fail. Second, the Partition Table must consist of 64 bytes starting at byte 1BE (counting from 0) of the MBR. The third is that two bytes after the partition table contain a signature 55AA in Hex. If the partition table is not present it will require substantial contrivances to allow multiple operating systems to reside on the drive. All major PC operating systems understand and use the Partition Table.
Classically, the Boot Program consisted of a small program that reads the partition table, identifies the active partition in the partition table, loads the boot record from the active partition and transfers control to that code. This arrangement was devised by IBM in the PC XT -- the first mass market IBM PC to support hard disks -- in order to allow users the option of booting multiple operating systems from one disk.
In later years, several alternatives have developed to the classical boot program. Disk Drive Overlays are programs that override BIOS limitations on disk size. DDOs get control in order to install themselves and override the normal BIOS INT 13 handling by replacing the Boot Record which they emulate after installing themselves. Boot sector viruses do something similar to DDOs, but not as helpful. Some boot sector viruses hide themselves by maintaining an image of the boot record which they return to the user if attempts are made to read the boot record. Boot managers replace the rather clumsy active partition selection of boot partition with more sophisticated, easier to use, OS selection methods.
A number of boot managers exist that permit booting of multiple OSes without the aggravation of altering the active partition flag for every boot. Boot managers may replace the standard, neutral boot program with a specialized program that may fail if the second stage program that it invokes has problems. Linux is notorious for this because it often is not clear to users that the lilo program is installing a boot manager when it installs to the MBR. The Microsoft FDISK utilities have an undocumented switch /MBR that replaces the MBR (but not the partition table) with a neutral Boot Record. Some Microsoft fdisks -- specifically NT's seem to have side affects to /MBR like removing the disk from an NT fault tolerant set.
The MBR (and the whole track it resides on) can not be allocated within the partition table and are not part of any file system. Most partitioning tools omit the entire first cylinder (the "system cylinder") of the disk from partitioning and leave it out of the reported drive size. OSes that replace the MBR often save the existing boot record in a file like Windows SUHDLOG.DAT. However, not all OSes provide a non-file system utility like Linux' dd that can be used to restore the MBR. The preferred DOS program for saving and restoring MBRs is RAWRITE. Ironically, RAWRITE is not a Microsoft product and is most easily found on Linux ftp sites.
The remainder of the boot cylinder after the boot record is unused by any partition. It is sometimes used by disk drive overlays, boot managers, and/or boot sector viruses for "invisible" program storage. It is also reported that some programs use bytes in the MBR that they fondly believe to be unused/expendable, for program storage. This is a dubious idea since the content of the MBR -- other than the partition table -- is not guaranteed, and the sector can contain almost anything in a multiple OS environment. The MSDOS Speedstore program is reported to have done that. It is also reported that some versions of Windows write some mysterious, and very likely unused, data into some normally unused MBR bytes,
The following web site contains a disassembled boot record.
http://bootmaster.filerecovery.biz/appnote4.html Note that the widely referenced disassembly at http://www.ata-atapi.com/hiwmbr.htm seems to have vanished and is not available via the Internet Archive.
The MBR program disassembled above moves itself out of the way since the buffer it is loaded in will be used for the OS boot record. It then checks for one (and only one) active partition. It loads the boot record for the active partition, checks for a signature 55AA hex in the last two bytes of the boot record, and transfers control to the code from the boot record.
The disassembled code recognizes three error conditions: "Invalid Partition Table" means multiple active partitions. "Error Loading Operating System" indicates I/O problems reading the boot record (5 tries are made). "Missing Operating System" indicates no 55AA signature on the partition boot record. If no active partition is found, INT18 is called to try to load ROM Basic -- something that will not work on any PC built since about 1985. Some BIOSes handle attempts to load ROM BASIC more gracefully than others. The BIOS itself will flag an error -- Probably "Drive Not Ready" if the MBR itself lacks a 55AA signature.
When all else fails, it may be necessary to abandon all the data on the drive by clearing out the MBR (including the partition table). The following site contained a description of how to do so from MSDOS and Linux. It also has disappeared, but perhaps can be tracked down.
In future years, Microsoft will release a version of Windows supporting a new, incompatible, MBR format known as GPT. The GPT is primarily associated with 64bit CPU versions of Windows and Linux.
Three different MBR programs have been used by Microsoft: One format was used in MSDOS 3.3 and earlier. The second is used by MSDOS after MSDOS 3.3 through Windows 95. The third is used on FAT32 disks. They are functionally similar. All the Microsoft MBRs are general purpose boot loaders with English (if weird) error messages.
For a thorough discussion of MBRs and issues see:
Return To Index Copyright 1994-2002 by Donald Kenney.