World Magazine 2024
Summary
Understanding the content and function of a file system “boot sector” can often be helpful in troubleshooting boot failures or disk corruption. A boot sector, usually due to hardware failure or virus infection, may become corrupted. If the partition where this sector resides is the active primary partition, or a partition containing operating system files, this corruption can prevent the system from starting. At the very least, it may simply prevent access to data on the drive.
In most cases, if you suspect disk corruption, it is best to use commercial anti-virus or disk recovery software to resolve the problem, however there are those cases where detailed knowledge of the boot sector can come in handy in making a repair.
Here we will review the various fields of a FAT boot sector. Although we make no guarantees, you may find that by using the following information, it may be possible to manually repair a damaged FAT boot sector. In order to attempt such a repair, disk editing tools capable of editing raw disk sectors is required. We will not be discussing any particular tools which can be used to perform such a repair operations.
While every effort has been made to ensure the accuracy of the following information, different operating systems, including future versions of Microsoft operating systems, may use different data structures. Therefore, if you intend to make use of the following information, you do so at your own risk. Bear in mind that this is a unification of the boot sectors of the FAT12, FAT16, and FAT32 file systems as this information is, for the most part, identical to each.
Background and Terminology
For the purposes of this discussion, a “file system boot sector” is the first physical sector on a logical volume. A logical volume might be a primary partition, a logical drive in an extended partition, or a composite of two or more partitions, as is the case with mirrors, stripe sets, and volume sets.
On floppy disks, the boot sector is the first sector on the disk. In the case of hard drives, the first sector is referred to as the “Master Boot Record” or “MBR.” This MBR is different from a file system boot sector and contains a partition table, which describes the layout of logical partitions on that hard drive. The file system boot sector would be the first sector in one of those partitions.
The x86 Boot Process
The boot process of x86-based personal computers (as opposed to RISC-based systems) makes direct use of a file system boot sector for executing instructions. The initial boot process can be summarized as follows:
- Power On Self Test (or POST) initiated by system BIOS and CPU.
- BIOS determines which device to use as the “boot device.”
- BIOS loads the first physical sector from the boot device into memory and transfers CPU execution to the start of that memory address. If the boot device is a hard drive, the sector loaded in step 3 is the MBR, and the boot process proceeds as follows:
- MBR code loads the boot sector referenced by the partition table for the “active primary partition” into memory and transfers CPU execution to the start of that memory address.
Up to this point, the boot process is entirely independent of how the disk is formatted and what operating system is being loaded. From this point on, both the operating and file systems in use play a part.
In the case of FAT volumes which have Windows NT installed, the FAT boot sector is responsible for identifying the location of the file “NTLDR” on the volume, loading it into memory, and transferring control to it.
Inside the FAT Boot Sector
Because the MBR transfers CPU execution to the boot sector, the first few bytes of the FAT boot sector must be valid executable instructions for an x86 CPU. In practice these first instructions constitute a “jump” instruction and occupy the first 3 bytes of the boot sector. This jump serves to skip over the next several bytes which are not “executable.” Following the jump instruction is an 8 byte “OEM ID”. This is typically a string of characters that identifies the operating system that formatted the volume.
Following the OEM ID is a structure known as the BIOS Parameter Block, or “BPB.” Taken as a whole, the BPB provides enough information for the executable portion of the boot sector, which will either cause the OS to load, or in the case of NT, enable the boot process to locate the NTLDR file. Because the BPB always starts at the same offset, standard parameters are always in a known location. Because the first instruction in the boot sector is a jump, the BPB can be extended in the future, provided new information is appended to the end. In such a case, the jump instruction would only need a minor adjustment. Also, the actual executable code can be fairly generic. All the variability associated with running on disks of different sizes and geometries is encapsulated in the BPB.
The BPB is stored in a packed (that is, unaligned) format. The following table lists the byte offset of each field in the BPB. A description of each field follows the table.
Field Offset Length ----- ------ ------ Bytes Per Sector 11 2 Sectors Per Cluster 13 1 Reserved Sectors 14 2 FATs 16 1 Root Entries 17 2 Small Sectors 19 2 Media Descriptor 21 1 Sectors Per FAT 22 2 Sectors Per Track 24 2 Heads 26 2 Hidden Sectors 28 4 Large Sectors 32 4
Restated for clarity
| Offset in Boot Sector | Length in Bytes | Mnemonic |
| 03 | 8 | OEM_Identifier |
| 0B | 2 | BytesPerSector |
| 0D | 1 | SectorsPerCluster |
| 0E | 2 | ReservedSectors |
| 10 | 1 | NumberOfFATs |
| 11 | 2 | RootEntries |
| 13 | 2 | NumberOfSectors |
| 15 | 1 | MediaDescriptor |
| 16 | 2 | SectorsPerFAT |
| 18 | 2 | SectorsPerHead |
| 1A | 2 | HeadsPerCylinder |
| 1C | 4 | HiddenSectors |
| 20 | 4 | BigNumberOfSectors |
| 24 | 4 | BigSectorsPerFAT |
| 28 | 2 | ExtFlags |
| 2A | 2 | FSVersion |
| 2C | 4 | RootDirectoryStart |
| 30 | 2 | FSInfoSector |
| 32 | 2 | BackupBootSector |
| 34 | 12d | Reserved |
This is the eight-byte ASCII string that identifies the system that formatted the disk. All eight characters are meaningful. Spaces or zeroes are appended if the name is less than eight characters long. As any other OEM name, this string is nice to display near to the other disk information, but it is absolutely useless for any other purpose.
Bytes Per Sector:
This is the size of a hardware sector and for most disks in use in the United States, the value of this field will be 512. All of the disks we have examined have contained 512 in this field, however DOS supports disks with different sector sizes. Early versions of DOS silently set this field to 512 and ignored whatever the original value was. If you always presume that this value will always be 512, we doubt that you will run into any problems with the disks that have a different sector size.
Sectors Per Cluster:
Because FAT is limited in the number of clusters (or “allocation units”) that it can track, large volumes are supported by increasing the number of sectors per cluster. The cluster factor for a FAT volume is entirely dependent on the size of the volume. Valid values for this field are 1, 2, 4, 8, 16, 32, 64, and 128. Query in the Microsoft Knowledge Base for the term “Default Cluster Size” for more information on this subject.
Reserved Sectors: This represents the number of sectors preceding the start of the first FAT, including the boot sector itself. It should always have a value of at least 1. There’s no difference from early addressing and Logical Block Addressing (LBA), as you still start from the LBA sector (0) relative to current partition. LBA (ReservedSectors) is always the beginning of the first FAT. However, for FAT12 and FAT16 this value is usually 1. For FAT32 it is 20h. At least one sector must always be reserved.
Number of FATs:
This is the number of copies of the FAT table stored on the disk. Typically, the value of this field is 2. FATs are consecutive on the disk, with the second copy of FAT right after the first. At all times there should be at least one copy of FAT present.
Root Entries:
This is the total number of file name entries that can be stored in the root directory of the volume. On a typical hard drive, the value of this field is 512. Note, however, that one entry is always used as a Volume Label, and that files with long file names will use up multiple entries per file. This means the largest number of files in the root directory is typically 511, however you will run out of entries long before that if long file names are used. Bear in mind that this value is zero if the root directory is not fixed. All FAT32 disks should contain a zero in this field, indicating that the root directory can be arbitrarily long. Otherwise, this field usually contains a value of 512. Each directory entry consumes 32 bytes. To avoid wasting space, RootEntries*32 should be divisible by BytesPerSector.
Number of Sectors: – Small Sectors
This field is used to store the number of sectors on the disk if the size of the volume is small enough. For larger volumes, this field has a value of 0, and we refer instead to the “Large Sectors” value which comes later. If the number of sectors is greater than 65,535, then this field is set to zero and the dword at BigNumberOfSectors contains the actual number of sectors. By NumberOfSectors we will refer to both that of NumberOfSectors and BigNumberOfSectors, both of which are used. Note that this field should contain the same or lesser value as the corresponding field in the partition table. If the values are not equal, the lesser of them should be used. NumberOfSectors should be large enough to contain at least the reserved sectors, all FAT copies, and the root directory, if any.
Large Sectors:
If the Small Sectors field is zero, this field contains the total number of sectors used by the FAT volume.
Some additional fields follow the standard BIOS Parameter Block and constitute an “extended BIOS Parameter Block.” The next fields are:
Field Offset Length ----- ------ ------ Physical Drive Number 36 1 Current Head 37 1 Signature 38 1 ID 39 4 Volume Label 43 11 System ID 54 8
Media Descriptor:
This byte provides information about the media being used. The following table lists some of the recognized media descriptor values and their associated media. Note that the media descriptor byte may be associated with more than one disk capacity.
Byte Capacity Media Size and Type F0 2.88 MB 3.5-inch, 2-sided, 36-sector F0 1.44 MB 3.5-inch, 2-sided, 18-sector F9 720 KB 3.5-inch, 2-sided, 9-sector F9 1.2 MB 5.25-inch, 2-sided, 15-sector FD 360 KB 5.25-inch, 2-sided, 9-sector FF 320 KB 5.25-inch, 2-sided, 8-sector FC 180 KB 5.25-inch, 1-sided, 9-sector FE 160 KB 5.25-inch, 1-sided, 8-sector F8 ----- Fixed disk
Sectors Per FAT:
This is the number of sectors occupied by each of the FATs on the volume. Given this information, together with the number of FATs and reserved sectors listed above, we can compute where the root directory begins. Given the number of entries in the root directory, we can also compute where the user data area of the disk begins. This field is zero for FAT32 drives, with the BigSectorsPerFAT containing the actual value.
Note that the Microsoft’s FAT32 boot loader will not work with FAT32 drives if SectorsPerFAT is not zero, and FAT12 and FAT16 loaders will not work with the drives if SectorsPerFAT is zero.
As with NumberOfSectors, by SectorsPerFAT we mean the appropriate value. It goes without saying, FAT should be long enough to contain all of the information about each of the clusters on the disk.
SectorsPerHead: (and SectorsPerTrack)
These values are a part of the apparent disk geometry in use when the disk was formatted. Sectors Per Head is the number of sectors grouped under one head. Likewise, HeadsPerCylinder reflects the number of cylinders per head. If this partition is a CHS partition, these values must be the same as those returned by BIOS. If they are not the same, you must consider that the disk has been mis-configured and that the partition is unusable. Note that the Microsoft boot loader alters the BIOS Diskette Parameters table by setting the SectorsPerTrack field of this structure to SectorsPerHead as read from the boot disk. The values in these fields do not matter for LBA partitions.
Hidden Sectors:
This is the number of sectors on the physical disk preceding the start of the volume, before the boot sector itself. It is used during the boot sequence in order to calculate the absolute offset to the root directory and data areas. Think of it as the number of sectors between the beginning of this partition and the partition table itself. This field should be the same as the “number of sectors preceding the partition” in the partition table. Note that it is not necessarily the physical LBA address of the first sector, as secondary partitions may exist. If the HiddenSectors are not the same as in the partition table, you may consider the boot sector as corrupted and the partition unusable. Note also that the high word usually contains garbage in old versions of DOS.
ExtFlags
If the left-most bit of ExtFlags value is set then only the active copy of FAT is changed. If the bit is cleared then FATs will be kept in synchronization. Disk analyzing programs should set this bit only if some copies of the FAT contain defective sectors. Low four bits define which copy should be active. As you see, only the first sixteen copies of the FAT may be selected active, so the disk is usable if and only if among the first sixteen copies at least one is usable. For this flag, FAT numbers start from zero. This check insures that the active FAT is less than NumberOfFATs.
The following fields below are defined for FAT32 disks only, and are defined differently for FAT12 and FAT16 as discussed more fully below.
FSVersion
This is the version of the file system. The high byte is the major version, the low byte is the minor version. Both are set to zero on Windows® 9x versions, 95 OSR2 and later. Normally this value should not be checked, however, the Microsoft boot loader does check it in certain cases, and it complains if it is not zero.
RootDirectoryStart contains the number of the first cluster for the root directory. In FAT 32 the root directory is stored like any other directory, in the cluster chain. Obviously, this implies that it may grow as necessary. The value in this field should be at least two.
FSInfoSectorThis is the sector number for the file system information sector. This sector is new to FAT 32. Its structure is below:
| Offset in Sector | Size | Definition |
| 00 | 4 | Signature, should be 41615252h (?) |
| 1E4 | 4 | Signature, should be 61417272h |
| 1E8 | 4 | Number of free clusters on the drive, or -1 if unknown |
| 1EC | 4 | Number of the most recently allocated cluster |
| 1F0 | 12d | Reserved |
| 1FE | 2 | Signature AA55 |
All the other bytes are set to zero. As you see, these values are introduced to improve performance. Make sure that FSInfoSector is at least one and it lies within the reserved disk area. Also make sure that this value is not the same as BackupBootSector. If it does not satisfy these conditions, do not use this sector, but the file system should still be usable. Do not use the information in this sector if its signature is incorrect. Note that only the second signature is documented by Microsoft. Normally, the number of free clusters is checked only by special disk analysis programs. FSInfoSector is usually one.
BackupBootSector
This is the sector number for the backup copy of the boot sector. This copy can be used if the main copy was corrupted. It is also nice to compare the two copies on startup. If they do not match, a warning should be issued. They may not be in tact because of corruption or a boot virus. If this field contains zero or the number greater than or equal to ReservedSectors or the same value as FSInfoSector, the backup sector should not be used.
Additional Information
Physical Drive Number:
This is related to the BIOS physical drive number. Floppy drives are numbered starting with 0x00 for the floppy drive (always “A” or “B”), while physical hard disks are numbered starting with 0x80. Typically, you would set this value prior to issuing an INT 13 BIOS call in order to specify the device to access. The on-disk value stored in this field is typically 0x00 for floppies and 0x80 for hard disks, regardless of how many physical disk drives exist, because the value is only relevant if the device is a boot device.
Current Head:
This is another field typically used when doing INT13 BIOS calls. The value would originally have been used to store the track on which the boot record was located, but the value stored on disk is not currently used as such. In Windows NT, this field is used to store two flags:
- The low order bit is a “dirty” flag, used to indicate that autochk should run chkdsk against the volume at boot time.
- The second lowest bit is a flag indicating that a surface scan should also be run.
Signature: The extended boot record signature must be either 0x28 or 0x29 in order to be recognized by Windows NT.
ID: The ID is a random serial number assigned at format time in order to aid in distinguishing one disk from another.
Volume Label:
This field was used to store the volume label, but the volume label is now stored as a special file in the root directory.
System ID:
This field is either “FAT 12” or “FAT 16,” depending on the format of the disk. Information on NTFS volumes will be found here: NTFS Directories and Files
On a bootable volume, the area following the Extended BIOS Parameter Block is typically executable boot code. This code is responsible for performing whatever action is necessary to continue the boot-strap process. On Windows NT systems, this boot code will identify the location of the NTLDR file, load it into memory, and then transfer the execution process to that file. Even on a non-bootable floppy disk, there is executable code in this area. The code necessary to print the familiar message, “Non-system disk or disk error” is found on most standard, MS-DOS formatted floppy disks that were not formatted with the “system” option.
Finally, the last two bytes in any boot sector always have the hexidecimal values: 0x55 0xAA.
Troubleshooting If you suspect that a FAT boot sector has become corrupt, you can check several of the fields listed above to see whether the values listed there make sense.
For example, BytesPerSector will be 512 in the vast majority of cases. You may also expect to see text strings in the executable code section of the boot sector that are appropriate for the operating system that formatted the disk.
Typical text strings on FAT volumes formatted by MS-DOS include: “Invalid system disk.”; “Disk I/O error.”; “Replace the disk, and then press any key”; “Non-System disk or disk error”; “Replace and press any key when ready.”; and “Disk Boot failure.”
Text strings on FAT volumes formatted by Windows NT include: “BOOT: Unable to (or Couldn’t) find NTLDR”; “I/O error reading disk.”; and “Please insert another disk.” By the way, you shouldn’t regard this list as being all inclusive. If you find other messages in the boot sector, this does not necessarily indicate that there is a problem with the boot sector.
Different versions of MS-DOS and Windows NT will sometimes have slightly different message strings in their boot sectors. On the other hand, if you find no text whatsoever, or if the text is clearly not related to MS-DOS or Windows NT, you should consider the possibility that your boot sector may have been infected by a virus or that some other form of data corruption may have taken place.
To recover from a boot sector that has been infected by a virus, it is usually best to use a commercial anti-virus program. Many viruses and Trojans will do much more than just write data to the boot sector, so manual repair of the boot sector is not recommended, as it may not completely eliminate the virus or Trojan and in some cases, may do more harm than good.
If you suspect that the boot sector was damaged for some other reason, it is usually best to use commercial disk recovery tools. While it may be possible to recover from boot sector damage without resorting to reformatting the drive by manually modifying the fields described above, manual editing of boot sectors should only be attempted as a last resort and cannot be guaranteed to work in situations where other disk structures may also have been damaged.
Notice: Windows® 95, Windows® 98, Windows® NT, Windows® 2000, Windows® XP and Microsoft® Office are registered trademarks or trademarks of the Microsoft Corporation.
All other trademarks are the property of their respective owners.
