Fact-checked by Grok 2 weeks ago

BIOS parameter block

The BIOS parameter block (BPB) is a embedded in the of a volume formatted with the () , providing critical about the volume's geometry, layout, and parameters necessary for operating systems and bootloaders to access and manage the medium. Introduced with 2.0 in the early 1980s to support floppy disks and hard drives, the BPB evolved across versions of the to accommodate larger capacities and varying media types, with significant updates in 3.0 for volumes exceeding 64 kilobytes and the introduction of in OSR2 for drives up to 2 terabytes. Its primary purpose is to enable file system drivers to interpret the volume's structure, including sector and cluster sizes, the location and size of file allocation tables (s), and details like the , ensuring compatibility across BIOS-based environments and legacy systems. The BPB occupies the first 25 bytes (offsets 11 to 35 in the 512-byte ) for basic and variants, extending to 90 bytes for to include additional fields like the root number and file system version. Key fields in the BPB define essential attributes, such as BPB_BytsPerSec (bytes per sector, typically 512), BPB_SecPerClus (sectors per , a power of 2 from 1 to 128), BPB_NumFATs (number of FAT copies, usually 2 for redundancy), and BPB_TotSec32 (total sectors on the volume for larger drives). For FAT32, unique extensions like BPB_FATSz32 specify the FAT size in sectors, while BPB_RootClus indicates the starting of the , replacing the fixed root entry count used in earlier FAT versions. These parameters, combined with media descriptors and volume serial numbers, allow for volume identification and error recovery, though the BPB's fixed format assumes interrupt services for low-level disk access, limiting its direct use in modern environments without emulation. Despite the rise of advanced file systems like and , the BPB remains relevant for compatibility with , embedded systems, and legacy boot processes.

Overview

Definition and Purpose

The (BPB) is a , typically 25–90 bytes long, embedded in the volume boot record (VBR) of a or . It serves as a foundational element in file systems like , containing that describes the physical and logical layout of the storage volume. The primary purpose of the BPB is to supply essential parameters to the operating system loader and BIOS routines for initializing and accessing the , including details on sector sizes, cluster counts, and () locations. This enables the boot process to interpret the volume's organization without requiring prior knowledge of the hardware specifics. Historically, the BPB was designed for compatibility with the PC BIOS, allowing access to storage media via low-level interrupts without full operating system intervention, and it originated in 2.0 as an evolution from earlier CP/M-derived formats. A key benefit is its role in standardizing volume layout descriptions, which facilitates cross-operating system mounting of compatible media, unlike many modern file systems that use dedicated superblocks for .

Location and Role in Boot Process

The BIOS parameter block (BPB) resides in the first sector, known as sector 0, of a logical or on the storage media. This sector, often referred to as the or volume boot record (VBR), begins with executable code: bytes 0–2 contain a jump instruction to skip to the boot code, and bytes 3–10 hold the OEM name identifying the formatting software or operating system. The BPB itself starts at byte 11 within this 512-byte sector and extends variably depending on the version, providing essential parameters for disk access without which the operating system cannot interpret the layout. During the boot process, the plays a central role in accessing the BPB by loading the via its disk services, specifically Interrupt 13h (). Following the (), the uses function AH=02h to read the from track 0, sector 1 (or equivalent logical block address) into at physical 07C00h, with parameters specifying the drive in DL, head in DH, cylinder in CH, and sector in CL. Once loaded, the code executes and transfers control to the operating system loader, such as IO.SYS in . The loader then parses the BPB starting at offset 11 to extract volume parameters, enabling it to calculate and locate the and () for loading subsequent system files like MSDOS.SYS. Access to the BPB and subsequent sectors occurs exclusively through disk services like , which handle low-level I/O translation between physical and logical addressing. Variations in BPB location and access arise based on the storage media. For non-partitioned media like floppy disks, the boot sector containing the BPB occupies the absolute first sector of the disk, with no preceding table, allowing direct access during . On partitioned hard disks, the (MBR) in the disk's first sector contains a table that specifies the starting sector of the active ; the loads this MBR first via , executes its code to identify the boot , and then reads the VBR (including the BPB) from that 's first sector. If the BPB is invalid or inconsistent—such as a mismatched media descriptor byte indicating an unrecognized disk type—the boot process fails, often resulting in errors reported by the operating system loader. In , IO.SYS may detect this during parsing and invoke Interrupt 24h for critical error handling, displaying messages like "Invalid " or prompting the user with "Abort, Retry, Fail?" options; unresolved issues halt booting to prevent . The itself may return error codes via , such as 0Ch for "media type not found" on diskettes or 04h for "sector not found" on fixed disks, requiring a system reset ( AH=00h) before retrying.

Historical Development

Origins in Early DOS Versions

The BIOS parameter block (BPB) originated in the development of early disk operating systems for the processor, beginning with , also known as QDOS, created by at Seattle Computer Products in 1980. designed as a quick implementation to demonstrate the capabilities of SCP's 8086 board, drawing inspiration from but optimizing for faster file access and larger volumes without fixed size limits. This system was licensed to Microsoft and adapted into MS-DOS 1.0, released in 1981 alongside the IBM PC, which targeted single-sided 5.25-inch floppy disks as the primary storage medium. MS-DOS 1.x versions, including 1.0 through 1.25, lacked a formal on-disk BPB, relying instead on hardcoded assumptions in the I/O subsystem for disk geometry and layout. These fixed parameters assumed 512-byte sectors, 40 tracks per disk, 8 sectors per track, and single-sided operation, yielding a 160 KB formatted capacity per floppy—sufficient for the PC's initial configuration but inflexible for variations. A single media descriptor byte in the provided minimal format identification, but the absence of a structured BPB meant no support for hard disks or alternative floppy densities, limiting compatibility to the original hardware setup. The introduction of a true BPB came with 2.0 in 1983, marking a pivotal advancement to accommodate the PC/XT's hard disk support and evolving floppy formats. This version embedded the BPB in the starting at offset 0x0B, providing essential geometry details like bytes per sector, sectors per cluster, and reserved sectors to enable dynamic volume configuration. The FORMAT.COM utility leveraged the BPB to create partitions on hard disks, allowing multiple logical volumes on a single physical drive and facilitating interchangeability. The initial BPB structure was compact at 13 bytes, adequate for FAT12 file systems on small volumes up to 10 MB. This design was influenced by the PC 's disk services, which exposed cylinder-head-sector (CHS) geometry to the operating system, necessitating a standardized way to translate parameters into layouts. The BPB addressed the growing need for media flexibility, as users increasingly employed double-sided floppies (360 ) and hard drives, ensuring could boot and operate across diverse storage without hardcoded limitations.

Evolution Through Microsoft Operating Systems

The BIOS Parameter Block (BPB) underwent significant enhancements starting with 3.0 in 1984 to accommodate the increasing storage capacities of emerging hardware, such as the 1.2 MB floppy drives introduced with the PC AT and hard drives up to 20 MB. This version introduced 16-bit cluster numbering in the BPB, enabling support for FAT16 file systems on volumes larger than 4 MB, which was a departure from the 12-bit limitations of earlier versions. By 3.2 in 1987 and 3.31 in 1987, the BPB was further extended to include fields for sectors per track, number of heads, hidden sectors (expanded to 32 bits), and total sectors (also 32 bits), allowing partitions up to 32 MB while maintaining with existing media. 4.0 in 1988 added the Extended BPB (EBPB) with a volume serial number—a 32-bit generated from the format time—to prevent errors from mounting identical s across systems, alongside fields for disk unit numbers and type to support multiple s like HPFS. These changes were driven by the rapid growth in storage from megabytes to tens of megabytes, necessitating more robust identification and layout descriptions. The introduction of FAT32 support in OSR2 in 1996, bundled with 7.10, marked a major evolution with native FAT32 support through an even more extended BPB, incorporating 32-bit sectors per FAT, FAT mirroring flags, and the root directory's starting , which enabled volumes up to 2 TB while preserving by allowing older bootloaders to ignore unused fields. This adaptation addressed the shift to gigabyte-scale storage in consumer PCs, ensuring the BPB could describe larger chains without breaking legacy applications. In the post-DOS era, the BPB remained integral to Windows NT-based systems for FAT compatibility; for instance, the bootloader in through XP parsed the BPB in FAT volume boot records to locate the during , and the BOOTMGR in and later continued this support for or setups. The design influenced subsequent file systems, such as introduced in with SP2 in 2006, which retained a BPB-like structure in its volume boot record to describe allocation units and volume layout for flash media up to exabyte scales. However, with the transition to firmware in the mid-2000s, the BPB's role diminished for primary boot volumes, as partition tables and EFI system partitions (formatted as FAT32) supplanted MBR-based modes, though Windows still parses BPB fields for any remaining FAT volumes to ensure compatibility. This deprecation reflects the broader move away from BIOS-limited storage addressing toward more scalable, secure environments.

General Structure

Core BPB Fields

The core BIOS Parameter Block (BPB) fields form the foundational set of parameters in the boot sector of volumes, providing essential details about the , allocation units, and volume structure to enable proper access and management. These fields, spanning offsets 11 through 35 in the boot sector, are mandatory across all BPB variants and ensure compatibility for basic volume operations, such as reading sectors and navigating the (). They originated in early implementations and have remained consistent in their core purpose, though later extensions build upon them for larger volumes. The following table summarizes the core BPB fields, including their offsets (relative to the boot sector start), sizes, typical values, and roles:
Field NameOffset (bytes)Size (bits)Typical Value(s)Purpose
Bytes per sector11–1216512Specifies the number of bytes in each sector, defining the smallest unit for read/write operations; valid values are 512, 1024, 2048, or 4096.
Sectors per cluster1381, 2, 4, 8 (powers of 2 from 1 to 128)Indicates the number of sectors grouped into one allocation unit (cluster), optimizing storage efficiency by reducing FAT overhead for small files.
Reserved sectors14–15161Counts the sectors reserved at the volume's beginning, typically including only the boot sector itself, before the FAT begins; must be at least 1.
Number of FATs1682Defines the count of FAT copies on the volume for redundancy and reliability during error recovery.
Root directory entries17–1816512 (for FAT12/FAT16)Specifies the maximum number of 32-byte entries in the root directory; the directory size is this value multiplied by 32 bytes, with 0 used in some extended variants.
Total sectors (small)19–2016Varies (for volumes under 32 MB)Provides a 16-bit count of total sectors on the volume; set to 0 if the 32-bit version is used instead.
Media descriptor2180xF8 (hard disks), 0xF0 (floppies)Identifies the media type, influencing FAT caching and interrupt behaviors; common values include 0xF0–0xFF for different storage media.
Sectors per FAT (small)22–2316Varies based on volume sizeGives the 16-bit sector count per FAT; determines the FAT's size and is set to 0 when using the extended 32-bit version.
Sectors per track24–251663 (common for hard disks)Describes the sectors per track in the BIOS geometry model, used for legacy interrupt 13h access to the disk.
Number of heads26–271616 or 255 (common for hard disks)Indicates the number of heads in the BIOS CHS addressing scheme for compatibility with early hardware.
Hidden sectors28–3132Varies (e.g., partition offset)Counts the sectors hidden before the volume's start, such as those in preceding partitions or track 0; 0 for non-partitioned media like floppies.
Total sectors (large)32–3532Varies (for volumes over 32 MB)Offers a 32-bit total sector count for larger volumes; used when the 16-bit field is 0, providing support for capacities beyond 32 MB.
These fields collectively enable the operating system to interpret the volume's layout without relying on external geometry data, bridging hardware constraints with file system logic. For instance, the bytes per sector and sectors per cluster parameters define the cluster size (bytes per sector × sectors per cluster), which balances space utilization and performance—smaller clusters minimize waste for tiny files, while larger ones reduce fragmentation on big drives. The BIOS geometry fields (sectors per track and number of heads) reflect the CHS (cylinder-head-sector) model from early PC BIOS, essential for booting on pre-LBA hardware, though modern systems often ignore them in favor of logical block addressing. The hidden sectors field is crucial for partitioned disks, allowing the BPB to account for the volume's offset within the physical device. While these core fields suffice for small volumes, extended BPB fields address limitations for larger or advanced configurations.

Extended BPB (EBPB) Fields

The Extended BIOS Parameter Block (EBPB) extends the core BPB by adding optional fields beginning at byte offset 36 within the of a volume, providing support for advanced features such as volume identification, drive-specific , and with larger . Introduced in DOS 3.4 in 1988, the EBPB adds 26 bytes for FAT12 and FAT16 volumes (extending the boot sector up to offset 61) and up to 54 bytes for FAT32 volumes (up to offset 89), enhancing volume portability by including unique identifiers that help operating systems distinguish between similar and prevent accidental swaps of identical volumes. For FAT12 and FAT16 volumes, the EBPB includes the following fields, which provide essential metadata for boot processes and file system recognition:
Field NameOffsetSize (bytes)Description
Physical Drive Number (BS_DrvNum)361An 8-bit value indicating the physical drive, such as 0x80 for the first hard drive or 0x00 for a floppy; used by boot code to identify the boot device during interrupt 13h calls.
Reserved (NT) (BS_Reserved1)371An 8-bit Windows-specific field, functioning as a flag related to bootable partitions and volume integrity checks; typically set to 0x00 during volume creation.
Signature (BS_BootSig)381An 8-bit value that must be 0x29 to validate the presence of the following EBPB fields.
Volume Serial Number (BS_VolID)39–424A 32-bit unique identifier generated by combining the current timestamp (date and time of formatting) with a pseudo-random element to ensure volume uniqueness across systems.
Volume Label (BS_VolLab)43–5311An ASCII string representing the volume name, padded with spaces if shorter than 11 characters; defaults to "NO NAME " if no label is specified, matching the root directory entry.
File System Type (BS_FilSysType)54–618An informational ASCII string identifying the file system, such as "FAT12 " or "FAT "; not used by Microsoft drivers to determine the actual FAT type but aids in compatibility.
For FAT32 volumes, the EBPB incorporates additional fields starting at offset 36 to accommodate larger structures, shifting the common fields (drive number, reserved, signature, etc.) to offsets 64–89; the BPB_FATSz16 field must be set to 0 to indicate FAT32 usage. These FAT32-specific fields include:
Field NameOffsetSize (bytes)Description
Sectors per FAT (BPB_FATSz32)36–394A 32-bit count of sectors occupied by each FAT table, allowing for larger file allocation tables.
FAT Flags (BPB_ExtFlags)40–412A 16-bit value indicating the active FAT (for non-mirrored setups) and mirroring behavior; bit 7 set to 1 disables mirroring.
File System Version (BPB_FSVers)42–43216-bit value indicating the file system version (high byte: major, low byte: minor; typically 0:0 for compatibility).
Root Cluster (BPB_RootClus)44–474A 32-bit number specifying the first cluster of the root directory (typically 2).
FSInfo Sector (BPB_FSInfo)48–492A 16-bit offset to the FSInfo structure sector (usually 1), which stores free cluster counts for optimization.
Backup Boot Sector (BPB_BkBootSec)50–512A 16-bit offset to the backup boot sector (usually 6), providing redundancy for boot parameters.
Reserved (BPB_Reserved)52–6312Reserved for future use; all bytes must be set to 0.
These EBPB fields collectively improve file system robustness and interoperability, particularly in multi-volume environments, by embedding descriptive directly in the without relying solely on core BPB parameters.

BPB for FAT File Systems

DOS 2.0 BPB (FAT12/FAT16)

The DOS 2.0 BIOS Parameter Block (BPB) was introduced in March 1983 alongside 2.0, representing the first iteration of the operating system to provide native support for hard disk drives with capacities up to 10 MB, in addition to media. This version shifted from earlier DOS reliance on implicit media detection via the first byte of the () to a structured BPB embedded in the for explicit volume parameterization, enabling more reliable initialization of FAT12 and FAT16 s. The BPB structure spans bytes 11 through 23 (offsets 0x0B to 0x17) of the 512-byte , comprising exactly 13 bytes and excluding any extended BPB (EBPB) fields that would appear in later versions. It incorporates the core BPB fields—such as bytes per sector (BPB_BytsPerSec, 2 bytes), sectors per cluster (BPB_SecPerClus, 1 byte), number of reserved sectors (BPB_RsvdSecCnt, 2 bytes), number of FATs (BPB_NumFATs, 1 byte), entries (BPB_RootEntCnt, 2 bytes), media descriptor (BPB_Media, 1 byte), and sectors per FAT (BPB_FATSz16, 2 bytes)—to define the basic layout of the volume. Distinct to this variant are its 16-bit limitations for total sectors (BPB_TotSec16, 2 bytes, maximum 65,535 sectors) and sectors per FAT (BPB_FATSz16, 2 bytes), which preclude support for larger volumes requiring 32-bit addressing. parameters such as sectors per track and number of heads are not stored in the BPB but are predefined for floppy media or detected via for hard drives. Among its constraints, the DOS 2.0 BPB omits fields for volume serial number and volume label, relying instead on the media descriptor byte for basic identification. It also assumes a fixed-size , typically configured for 512 entries (16 at 32 bytes per entry) to maximize , without provisions for dynamic as seen in subsequent file systems. These design choices reflect the era's constraints, limiting FAT12 volumes to under 16 and FAT16 to 32 in practice, though the 10 hard disk support utilized larger 4 clusters to accommodate the era's drives. A representative example illustrates its application: for a standard 360 KB double-sided 5.25-inch (formatted double density), the BPB sets sectors per cluster to 2 (yielding 1 KB clusters), total sectors to , root directory entries to 112, sectors per FAT to 2, and media descriptor to 0xFE, ensuring proper organization. The geometry (9 sectors per track, 2 heads, 80 tracks) is predefined for this . In terms of compatibility, the BPB is parsed by the command interpreter during the boot process to load the into memory and mount the volume, while the utility generates and writes the BPB tailored to the detected , such as floppies or early hard disks. This minimalistic format ensured broad interoperability with 2.0's utilities and hardware but necessitated upgrades in later versions for scaling to larger storage.
OffsetSize (bytes)Field NameDescription
112BPB_BytsPerSecBytes per logical sector (typically 512)
131BPB_SecPerClusSectors per (power of 2, e.g., 2 for 1 )
142BPB_RsvdSecCntNumber of reserved sectors (usually 1)
161BPB_NumFATsNumber of copies (typically 2)
172BPB_RootEntCntNumber of entries (e.g., for 360 KB floppy)
192BPB_TotSec16Total sectors in volume (16-bit; maximum 65,535)
211BPB_MediaMedia descriptor (e.g., 0xFE for 360 KB floppy)
222BPB_FATSz16Sectors per FAT (16-bit)
This table outlines the 13-byte layout, with all fields in little-endian format, as defined for FAT12 and FAT16 volumes in 2.0.

DOS 3.0–3.31 BPB (FAT12/FAT16)

The BIOS Parameter Block (BPB) for versions 3.0 through 3.31, spanning from its initial release in August 1984 to the 3.31 update in late 1987, refined the structure introduced in earlier versions to better accommodate hard disk drives and emerging media formats while supporting FAT12 and FAT16 file systems. This iteration added geometry and partition fields but did not incorporate a full Extended BPB (EBPB). The structure varied slightly between subversions: for DOS 3.0 to 3.30, it occupies bytes 11 through 29, including a 2-byte hidden sectors field at offsets 28–29; for DOS 3.31, it extends to bytes 11 through 35, with a 4-byte hidden sectors field at offsets 28–31 and the addition of a 32-bit total sectors field (BPB_TotSec32) at offsets 32–35. This BPB_TotSec32 field, used only when BPB_TotSec16 is set to zero, allowed for partitions up to 2 GB in size for FAT16 volumes when using larger cluster sizes like 32 KB—surpassing the 16-bit total sectors limit (BPB_TotSec16 at offsets 19–20) that capped earlier volumes at around 32 MB. The BPB structure in this era maintained core fields for physical and logical volume description, such as bytes per sector (offsets 11–12, typically 512), sectors per cluster (offset 13, a power of 2), number of reserved sectors (offsets 14–15, usually 1), number of FATs (offset 16, often 2), root directory entries (offsets 17–18, fixed at 512 for many configurations), media descriptor (offset 21), and sectors per FAT (offsets 22–23). Additional geometry fields included sectors per track (offsets 24–25), number of heads (offsets 26–27), and hidden sectors (offsets 28–29 for DOS 3.0-3.30 or 28–31 for 3.31), which FDISK.COM populated during partitioning to indicate sectors preceding the volume's start, making the BPB indispensable for multi-partition setups on hard drives. For instance, on a typical 20 MB hard disk drive formatted under DOS 3.x, the BPB would specify 512 bytes per sector, 9 sectors per FAT for a FAT12 layout (though larger drives often shifted to FAT16), and 512 root directory entries to balance directory size with sector alignment. Sub-version changes further tailored the BPB for new hardware. DOS 3.2, released in 1986, incorporated support for 1.44 MB high-density 3.5-inch floppy disks by allowing sectors per cluster values of 1, optimizing for the increased capacity while preserving with smaller . In DOS 3.31, refinements to the media descriptor byte (offset 21) extended compatibility to CD-ROM drives, using values like 0xF8 to denote non-removable optical , which facilitated integration with MSCDEX.EXE for accessing volumes alongside structures. These evolutions built on the minimal BPB from DOS 2.0 by emphasizing hard and volume scaling, ensuring robust operation in environments with multiple drives or emerging peripherals.

DOS 4.0 EBPB (FAT12/FAT16/HPFS)

The DOS 4.0 Extended BIOS Parameter Block (EBPB) represents the first comprehensive extension of the BPB structure, introduced in 1988 with 4.0 and used in 1.x, including HPFS support in the Extended Edition released that year, to support larger volumes up to 2 GB while incorporating additional metadata for volume identification and file system typing. Spanning 51 bytes from offsets 11 to 61 (0x0B to 0x3D) in the boot sector, it builds on prior DOS versions by adding fields for enhanced compatibility and redundancy, particularly for FAT12 and FAT16 s on hard disks. This structure maintains the core geometry parameters—such as bytes per sector, sectors per cluster, and reserved sectors—while extending to include drive-specific and volume-specific details, enabling more robust boot processes and management. Key unique features of the DOS 4.0 EBPB include a boot signature byte of 0x29 at offset 38 (0x26 in the boot sector), which validates the structure's integrity; a physical drive number byte at offset 36 (0x24), indicating the boot device (e.g., 0x80 for the first hard drive); a 32-bit volume serial number at offsets 39–42 (0x27–0x2A), typically generated as (creation time shifted left by 16 bits) OR a random value for uniqueness; an 11-byte volume label at offsets 43–53 (0x2B–0x35), truncated to uppercase ASCII if longer; and an 8-byte file system type string at offsets 54–61 (0x36–0x3D), such as "FAT12 " or "FAT16 ". The sectors per FAT field remains 16-bit, limiting FAT sizes but supporting volumes up to the 2 GB threshold, with two FAT copies providing redundancy for backup and recovery. For example, during formatting, the volume serial might combine the high word of the creation timestamp with a pseudorandom low word to ensure collision resistance across disks. The EBPB was adapted for HPFS in , using the identical structure for but differentiating via the type field set to "HPFS ", while setting sectors per cluster to 4 to align with HPFS's 2 KB allocation units (though the BPB primarily describes physical rather than logical ing). This adaptation focuses on disk parameters like sectors per track and number of heads, ensuring without altering the core EBPB footprint. The structure's extensions, including the volume serial and , facilitate through the dual FATs (or equivalent in HPFS for ), allowing recovery from primary FAT corruption by referencing the backup. The 4.0 EBPB enables dual-boot configurations on the same disk by standardizing metadata, permitting seamless switching between and HPFS partitions without geometry conflicts. This compatibility allows a single disk to host both file systems, with the EBPB's drive number and serial fields aiding the in identifying and mounting the appropriate volume during or startup.

FAT32 EBPB (DOS 7.10)

The FAT32 Extended BIOS Parameter Block (EBPB) was introduced in MS-DOS 7.10 in 1996 alongside Windows 95 OEM Service Release 2, enabling support for volumes exceeding the 2 GB limit imposed by FAT16 through 32-bit cluster addressing and enhanced metadata structures. This expansion addressed the growing capacity of hard drives in the mid-1990s, allowing more efficient space utilization with smaller cluster sizes while maintaining backward compatibility with core FAT principles. The structure builds upon the DOS 4.0 EBPB by extending fields for larger-scale operations, without altering the fundamental boot sector layout. The FAT32 EBPB comprises 90 bytes, spanning offsets 11 through 100 in the 512-byte , and includes all preceding BPB fields up to BPB_TotSec32 at offset 32–35, followed by FAT32-specific extensions starting at offset 36. These additions facilitate management of massive file allocation tables and dynamic handling essential for terabyte-scale . The type is identified by the "FAT32 " at offset 82–89, distinguishing it from earlier variants. Key extensions in the FAT32 EBPB include the 32-bit sectors per FAT count (BPB_FATSz32) at offset 36–39, which supersedes the 16-bit BPB_FATSz16 (set to 0) and removes size restrictions on tables, enabling volumes with millions of clusters. The extended flags (BPB_ExtFlags) at offset 40–41 allow configuration of FAT : bit 7 set to 1 disables mirroring for single-FAT use to conserve space, while bits 0–3 select the active FAT when disabled; bit 7 set to 0 maintains traditional mirroring across copies. Further enhancements specify the root directory's starting (BPB_RootClus) at offset 44–47, defaulting to 2, which treats the root as a regular chain rather than a fixed pre-allocated region, thus eliminating the 32 MB root limit of 16 and supporting unlimited subdirectory nesting. The FSInfo sector location (BPB_FSInfo) at offset 48–49 points to a dedicated structure—typically sector 1—storing the free count and next available number for optimized allocation during operations. The backup offset (BPB_BkBootSec) at offset 50–51, usually 6, ensures redundancy by duplicating the boot sector, BPB, and FSInfo for recovery from corruption.
OffsetField NameSize (bytes)Description
36–39BPB_FATSz32432-bit sectors occupied by each (BPB_FATSz16 = 0).
40–41BPB_ExtFlags2 control flags: bit 7 ( disable), bits 0–3 (active ).
44–47BPB_RootClus4First of (default: 2).
48–49BPB_FSInfo2Sector number of FSInfo structure (default: 1).
50–51BPB_BkBootSec2Sector number of (default: 6).
FAT32 volumes have no fixed root directory size, relying instead on cluster chains for scalability, which contrasts with the static allocation in prior EBPBs and enhances performance on large drives by reducing wasted space. Although the specification theoretically supports up to 16 TB via larger cluster sizes (e.g., 64 KB clusters yielding approximately 268 million clusters), Microsoft recommends a 2 TB maximum to ensure compatibility with tools and avoid fragmentation issues. For a representative 32 GB volume, the EBPB might configure 16 sectors per (8 KB clusters for efficient small-file storage), approximately 250 sectors per FAT using 32-bit entries, and the "FAT32 " identifier, balancing overhead with capacity for around 4 million . This configuration is prevalent in USB flash drives and other removable media, where FAT32's cross-platform readability—supported by Windows, macOS, , and embedded devices—prioritizes over advanced features. In and later 7.1-based environments, utilities like SCANREG /SCAN leverage the FAT32 EBPB to scan and back up registry files on such volumes.

Boot Sector Parameters in Other File Systems

NTFS Boot Sector

The NTFS boot sector, also known as the volume boot record (VBR), occupies the first sector of an NTFS volume and provides essential parameters for accessing the file system structure, analogous to the BIOS parameter block in FAT but tailored to NTFS's master file table (MFT)-centric design. Although not officially termed a BPB, it features an 81-byte parameter area from offsets 3 to 83 within the 512-byte sector, beginning with a jump instruction at offset 0 (3 bytes) followed by the OEM identifier "NTFS " at offsets 3–10. This structure enables the operating system loader to initialize the volume, with a backup copy typically located at the end of the volume for redundancy. Key fields in the NTFS boot sector describe fundamental volume geometry and metadata locations. The bytes per sector field at offset 11 (2 bytes) specifies the sector size, commonly 512, 1024, 2048, or 4096 bytes. The sectors per cluster field at offset 13 (1 byte) defines the cluster size as a power of 2 (1 to 128 sectors), resulting in allocation units up to 64 KB, which influences features like file compression (using 4 KB or 16 KB units) and disk quotas. The MFT starting cluster number at offset 48 (8 bytes) usually points to cluster 0, while the MFT mirror cluster at offset 56 (8 bytes) defaults to cluster 1, ensuring redundancy for critical metadata. The volume serial number at offset 72 (8 bytes) uniquely identifies the volume, and the total sectors field at offset 40 (8 bytes) supports volumes up to 2^64 sectors, equivalent to approximately 9,444 exabytes (or 9.44 zettabytes) at 512 bytes per sector. Unlike FAT's focus on file allocation tables, the NTFS boot sector emphasizes MFT positioning and parameters without equivalents for FAT copies or entries, prioritizing journaling, , and large-scale storage. These parameters are parsed by the Windows () during mount to locate the $Boot and initialize access. For example, on a 100 NTFS , the sectors per might be set to 8 (yielding 4 with 512-byte sectors), with the MFT at 0 allocated an initial extent of about 16 to accommodate . The remaining space from offset 84 to 509 contains bootstrap code, followed by the sector signature 0xAA55 at offsets 510–511.

exFAT Boot Record

The exFAT boot record, part of the Extended File Allocation Table () file system, was introduced in 2006 as part of Windows CE 6.0 to address limitations in FAT32 for devices, such as support for larger volumes and files without the 4 GB file size restriction. The main spans the first 12 sectors (0–11) of the volume and contains boot code along with fundamental parameters describing the volume structure, including 64-bit addressing for volumes up to approximately 128 PB and cluster sizes up to 32 MB. A backup mirrors this structure in sectors 12–23 for purposes, while main and backup OEM parameter sectors (9–10 and 21–22) store up to 10 custom parameter sets, such as flash media parameters, that are preserved during formatting. Key fields in the main boot sector provide essential volume metadata, sharing conceptual similarities with FAT32's extended BPB but optimized for exFAT's simpler allocation model. These include the bytes per sector shift (offset 108, 1 byte, log₂ value from 9 to 12 for 512–4096 bytes), sectors per cluster shift (offset 109, 1 byte, log₂ up to 25 for maximum 32 MB clusters), number of FATs (offset 110, 1 byte, typically 1), FAT offset (offset 80, 4 bytes, starting sector of the FAT), FAT length (offset 84, 4 bytes, length in sectors), cluster heap offset (offset 88, 4 bytes, starting sector of the cluster area), cluster count (offset 92, 4 bytes, up to 2³²–11), first cluster of root directory (offset 96, 4 bytes), volume serial number (offset 100, 4 bytes), and file system revision (offset 104, 2 bytes). The file system name "EXFAT " (with trailing spaces) appears at offset 3 (8 bytes), and reserved fields like "MustBeZero" (offsets 11–63, 53 bytes) ensure compatibility distinction from older FAT variants. Additional flags include volume flags (offset 106, 2 bytes, indicating states like active FAT or dirty volume) and percent in use (offset 112, 1 byte, allocated cluster percentage). Unlike traditional FAT systems with multiple chained FAT copies, exFAT employs a single FAT as an allocation (1 bit per ) for efficient large-scale management, eliminating the need for separate read/write FATs and supporting up to 2²⁸ in practical implementations. The boot code (offsets 120–509, 390 bytes) handles , ending with a (offsets 510–511, AA55h), while is ensured by checksum sectors at 11 and 23, each containing a 4-byte of the respective (excluding modifiable fields like volume flags and percent in use) computed via a specific 32-bit . For example, on a 64 exFAT-formatted SD card (approximately 131,072,000 sectors of 512 bytes), a typical configuration uses a 32 cluster size (64 sectors per cluster, sectors per cluster shift = 6), resulting in about 2,000,000 clusters; the FAT length would then be roughly 500 sectors to accommodate the bitmap (2,000,000 bits ≈ 250 ). This setup allows efficient handling of large files exceeding 4 , making exFAT ideal for cross-platform storage on flash media. exFAT boot records are natively supported in with the KB955704 update (effectively SP2+), SP1 and later, macOS 10.6.5 and subsequent versions, enabling seamless file exchange for volumes and files beyond FAT32 limits.

References

  1. [1]
    [PDF] Microsoft FAT Specification - CBA
    Aug 30, 2005 · The BPB in the boot sector of a FAT volume must always have all of the BPB fields for either the. FAT12/FAT16 or FAT32 BPB type. This ensures ...
  2. [2]
    13. Protocols – Media Access - UEFI Forum
    The first block (sector) of a partition contains a data structure called the BIOS Parameter Block (BPB) that defines the type and location of FAT file system on ...
  3. [3]
    [MS-FSCC]: FSCTL_QUERY_FAT_BPB Request | Microsoft Learn
    The first 0x24 bytes of sector 0 are known as the FAT BIOS Parameter Block (BPB), which contains hardware-specific bootstrap information. This message does ...
  4. [4]
    [PDF] Microsoft Extensible Firmware Initiative FAT32 File System ...
    The first important data structure on a FAT volume is called the BPB (BIOS Parameter Block), which is located in the first sector of the volume in the ...
  5. [5]
    BPB - Geoff Chappell, Software Analyst
    Oct 28, 2021 · The BPB, standing for BIOS Parameter Block, is the structure through which the DOS kernel is told about a disk drive or about media, i.e., disks ...Missing: authoritative | Show results with:authoritative
  6. [6]
    FGA: All about BIOS parameter blocks
    A BIOS parameter block is a variant record embedded within the boot block (block zero) of a disc volume. It describes the volume's filesystem format.Missing: authoritative | Show results with:authoritative
  7. [7]
    Section II: Programming in the MS-DOS Environment - PCjs Machines
    MS-DOS system initialization (SYSINIT) MS-DOS system initialization begins after the operating-system loader has loaded IO. ... (BPB) in the disk boot sector.
  8. [8]
    [PDF] in IBM's PS/2 and PC BIOS Interface Technical Reference
    This technical reference provides Basic Input/Output System (BIOS) and Advanced BIOS (ABIOS) interface information. It is intended for developers who provide ...
  9. [9]
    Microsoft MS-DOS early source code - Computer History Museum
    Mar 25, 2014 · Microsoft proposed licensing “86-DOS”, which had been written by Tim Paterson at Seattle Computer Products (SCP) for their 8086-based computer ...
  10. [10]
    The Roots of DOS
    Around April 1981, while he was doing some internal changes on 86-DOS--modifying system calls and including error handling for hard disks--Paterson decided to ...
  11. [11]
    DOS boot sector, BPB, and the media descriptor byte | OS/2 Museum
    Jul 25, 2011 · DOS 2.0 therefore created the concept of a BIOS Parameter Block—or BPB—which contained basic disk geometry information. It was stored in the ...
  12. [12]
    Floppy drive detection on an IBM PC 5150 by PC/MS-DOS
    Aug 19, 2023 · DOS simply used the defaults of the BIOS, and thus DOS 1.00 supported only 160KB SSDD floppies, with 8 sectors of 512 bytes per track. Having 40 ...What other tricks were there to get more data onto floppy disks?Was sector size under software control on the original IBM PC floppy ...More results from retrocomputing.stackexchange.com
  13. [13]
    Floppy Disk / Boot Sector / BPB // retrocmp / retro computing
    The boot sector (VBR) contains the BIOS Parameter Block (BPB), which provides disk parameters for DOS to recognize different floppy disk formats.
  14. [14]
    INT 13H - Wikipedia
    INT 13h is shorthand for BIOS interrupt call 13 hex, the 20th interrupt vector in an x86-based (IBM PC-descended) computer system.Missing: process | Show results with:process
  15. [15]
    Wrapping Up Support for FAT - PCjs Machines
    Sep 5, 2023 · BPBs (BIOS Parameter Blocks) are data structures introduced by DOS 2.00 and embedded in the DOS boot sector to describe the structure of the ...
  16. [16]
    NTFS Partition Boot Sector
    On NTFS volumes, the data fields that follow the BPB form an extended BPB. The data in these fields enables Ntldr (NT loader program) to find the master file ...
  17. [17]
    exFAT File System Specification - Win32 apps - Microsoft Learn
    3.1.3 MustBeZero Field. The MustBeZero field shall directly correspond with the range of bytes the packed BIOS parameter block consumes on FAT12/16/32 volumes.
  18. [18]
    How to Convert the System from Legacy BIOS mode to UEFI ... - Intel
    UEFI mode is compatible with the GUID Partition Table (GPT) partition style while the legacy BIOS mode is compatible with the Master Boot Record (MBR) partition ...<|control11|><|separator|>
  19. [19]
    FAT Filesystem - Elm-chan.org
    Boot Sector and BPB. The most important data structure in the FAT volume is BPB (BIOS Parameter Block), where the configuration parameters of the FAT volume ...
  20. [20]
    DOS 2.0 and 2.1 | OS/2 Museum
    Hard disks are yet another story, for example a DOS 2.0 30 MB hard disk gets formatted with 1024 root directory entries. DOS does not limit the number of ...
  21. [21]
    MS-DOS 3 - BetaWiki
    Sep 30, 2025 · MS-DOS 3 is a family of versions of MS-DOS, initially released in August 1984. MS-DOS 3. Version of MS-DOS · MS-DOS-3-31-Command-Line.
  22. [22]
    FAT - OSDev Wiki
    The Boot Sector is always placed at logical sector number zero. You can either read the boot sector into an array and access it's members that way or you can ...
  23. [23]
  24. [24]
    ms dos - What was the initial size of the file allocation table for a ...
    Oct 29, 2024 · With the updated MS-DOS 3.31 ... I did not test 20MB drive - it could be formatted as FAT16 or FAT12 depending on the threshold it has for ...
  25. [25]
    [PDF] Undocumented DOS - Bitsavers.org
    ... (Gordon Letwin, Inside OS/2, Redmond, WA: Microsoft Press, 1988, pp. 20-21). In other words, when popular applications use undocumented DOS, it's ulti ...
  26. [26]
    Overview of FAT, HPFS, and NTFS File Systems - Windows Client
    Jan 15, 2025 · FAT partitions are limited in size to a maximum of 4 Gigabytes (GB) under Windows NT and 2 GB in MS-DOS. For further discussion of other ...
  27. [27]
  28. [28]
    Description of FAT32 File System
    Jun 25, 1998 · This article describes the FAT32 file system included with Windows 95 OEM Service Release 2 (OSR2) and Windows 98.
  29. [29]
    this Batch file
    rem FAT32 FILE SYSTEM rem ================= rem rem The FAT32 file system is a method for storing files on a computer's rem hard disk, using magnetic storage.
  30. [30]
    $$Boot (7) - File - NTFS Documentation
    Because this file begins with a boot sector, it must start at physical cluster 0 (this is the only cluster that NTFS can not move). This forces the data ...Missing: kernel | Show results with:kernel
  31. [31]
    Tech Licensing Programs: exFAT and more | Microsoft Legal
    Extended File Allocation Table (exFAT) is Microsoft-patented file system. exFAT can handle extremely large file sizes and enables seamless file exchange between ...