Hubbry Logo
Volume boot recordVolume boot recordMain
Open search
Volume boot record
Community hub
Volume boot record
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Volume boot record
Volume boot record
Volume boot record
View on Wikipedia
from Wikipedia

A volume boot record (VBR) (also known as a volume boot sector, a partition boot record or a partition boot sector) is a type of boot sector introduced by the IBM Personal Computer. It may be found on a partitioned data storage device, such as a hard disk, or an unpartitioned device, such as a floppy disk, and contains machine code for bootstrapping programs (usually, but not necessarily, operating systems) stored in other parts of the device. On non-partitioned storage devices, it is the first sector of the device. On partitioned devices, it is the first sector of an individual partition on the device, with the first sector of the entire device being a Master Boot Record (MBR) containing the partition table.

The code in volume boot records is invoked either directly by the machine's firmware or indirectly by code in the master boot record or a boot manager. Code in the MBR and VBR is in essence loaded the same way.

Invoking a VBR via a boot manager is known as chain loading. Some dual-boot systems, such as NTLDR (the boot loader for all releases of Microsoft's Windows NT-derived operating systems up to and including Windows XP and Windows Server 2003), take copies of the bootstrap code that individual operating systems install into a single partition's VBR and store them in disc files, loading the relevant VBR content from file after the boot loader has asked the user which operating system to bootstrap. In Windows Vista, Windows Server 2008 and newer versions, NTLDR was replaced; the boot-loader functionality is instead provided by two new components: WINLOAD.EXE and the Windows Boot Manager.

In file systems such as FAT12 (except for in DOS 1.x), FAT16, FAT32, HPFS and NTFS, the VBR also contains a BIOS Parameter Block (BPB) that specifies the location and layout of the principal on-disk data structures for the file system. (A detailed discussion of the sector layout of FAT VBRs, the various FAT BPB versions and their entries can be found in the FAT article.)

Technical details

[edit]

Signature

[edit]

The presence of an IBM PC compatible boot loader for x86-CPUs in the boot sector is by convention indicated by a two-byte hexadecimal sequence called the boot sector signature (55h at fixed offset +1FEh and AAh at +1FFh) for sector sizes of 512 bytes or more.[nb 1] For 512 byte sectors, the boot sector signature also marks the end of the sector. VBRs on smaller and larger sectors may show signatures at the end of the actual sector size as well, however, the semantics described herein apply to the 16-bit signature at +1FEh only.

This signature indicates the presence of at least a dummy boot loader which is safe to be executed, even if it may not be able to actually load an operating system. It does not indicate the presence of a (or even a particular) file system or operating system, although some old versions of DOS prior to 3.3 relied on it in their process to detect FAT-formatted media (newer versions do not). Boot code for other platforms or CPUs should not use this signature, since this may lead to a crash when the BIOS passes execution to the boot sector assuming that it contains valid executable code. This implies that FAT12/FAT16 media to be used also by very old versions of DOS must maintain the signature even if they do not contain an operating system or are meant to be bootable on other platforms only; consequently they must contain at least an x86 compatible (dummy) loader as well (for comparison, see examples of FAT on the Atari ST and with MSX-DOS). Nevertheless, some media for other platforms erroneously contain the signature even without a x86 compatible dummy loader, making the check not 100% reliable in practice.

The signature is tested for by most System BIOSes since (at least) the IBM PC/AT (but not by the original IBM PC and some other machines). Even more so, it is also checked by most MBR boot loaders before passing control to the boot sector. Some BIOSes (like the IBM PC/AT) perform the check only for fixed disk / removable drives, while for floppies and superfloppies it is enough to start with a byte greater or equal to 06h and the first nine words not to contain the same value, before the boot sector is accepted as valid, thereby avoiding the explicit test for 55h, AAh on floppies. Since old boot sectors (i.e. very old CP/M-86 and DOS media) sometimes do not feature this signature despite the fact that they can be booted successfully, the check can be disabled in some environments. This also reflects the fact that floppies can be formatted to use smaller sector sizes than 512 bytes.

If the BIOS or MBR code does not detect a valid boot sector and therefore cannot pass execution to the boot sector code, it will try the next boot device in the row. If they all fail it will typically display an error message and invoke INT 18h.[1] This will either start up optional resident software in ROM (ROM BASIC), attempt to remote boot via network, reboot the system via INT 19h after user confirmation, or cause the system to halt the bootstrapping process until the next power-up.[1]

From decimal offset 72 to 79, an NTFS PBR contains the partition UUID volume ID serial number.

Invocation

[edit]

The boot code in the VBR can assume that the BIOS has set up its data structures and interrupts and initialized the hardware. The code should not assume more than 32 KB of memory to be present for fail-safe operation;[1] if it needs more memory it should query INT 12h for it, since other pre-boot code (such as f.e. BIOS extension overlays, encryption systems, or remote bootstrap loaders) may be present elsewhere in memory as well (and would typically hide themselves from the boot sector by reducing the reported INT 12h memory accordingly, so that they do not get overwritten by the MBR's and VBR's actions). The BIOS Boot Specification allows for 64 KB of memory and explicitly recommends 0000h:7C00h to 0000h:FFFFh as memory space for MBR and/or VBR.[2][1] The boot code must not assume better CPUs than the original Intel 8088 or 8086 (used in the original PC) and make no assumptions in regard to the exact state of the hardware, the interrupt system (interrupts can be enabled or disabled) or the location and size of the stack. Although the original IBM BIOS initializes the DS, ES, and SS CPU registers to segment 0000h and maintains the initial stack at SS:SP = 0000h:0400h, this is not a condition to rely on, as not all BIOSes and MBR codes follow this convention. Registers not mentioned below must be treated as not initialized. Direct hardware access is not normally allowed. While the Disk Parameter Table (DPT/FDPB) is typically set up at 0000h:0078h in memory already, the VBR must move (and possibly fix-up) the DPT pointed to by INT 1Eh vector to this location (INT 1Eh not an interrupt, but a far pointer to the DPT).

Some conditions can be relaxed in controlled environments, for example, some boot loaders today assume to have up to 128 KB of memory to work with in normal operation (without querying for more), and some boot loaders using LBA access assume at least an Intel 80188 or 80186 CPU.

The VBR is loaded at memory location 0000h:7C00h[1] and with the following CPU registers set up when the prior bootstrap loader (that is, typically the BIOS or MBR, but possibly another boot loader) passes execution to it by jumping to 0000h:7C00h in the CPU's real mode.

  • CS:IP = 0000h:7C00h (fixed)

Some Compaq BIOSes erroneously use 07C0h:0000h instead. While this resolves to the same location in real mode memory, it is non-standard and should be avoided, since VBR code assuming certain register values or not written to be relocatible may not work otherwise.

  • DL = boot drive unit (floppies / superfloppies: 00h = first, 01h = second, ..., 7Eh; fixed disks / removable drives: 80h = first, 81h = second, ..., FEh; values 7Fh and FFh are reserved for ROM / remote drives and must not be used on disk).[3] DL is supported by IBM BIOSes as well as most other BIOSes. The Toshiba T1000 BIOS is known to not support this properly, and some old Wyse 286 BIOSes use DL values greater or equal to 2 for hard disks. USB sticks configured as superfloppies typically get an assignment of DL = 00h or 01h, however, some rare BIOSes erroneously present USB sticks configured as removable drives as DL = 01h as well, instead of using DL = 80h. Traditionally, only values 00h and 80h were passed on by the BIOS during boot, and many boot sectors were hard-wired to work with fixed values, anyway. The Plug and Play BIOS Specification and BIOS Boot Specification (BBS) allow other devices to become bootable as well.[2][4] The later also recommends that the MBR and VBR codes use DL rather than internally hardwired defaults.[2] (NB. MS-DOS/PC DOS and OS/2 VBRs ignore the provided DL value and instead retrieve the value stored at offset +19h in the Extended BIOS Parameter Block (EBPB) or at sector offset +1FDh in DOS versions 3.2 to 3.31. Some versions of DR-DOS use DL starting with 7.02. DR-DOS 7.07 VBRs default to use DL and ignore the BPB value, but SYS /O[:nnn] can be used to reinvoke the old behaviour of using the BPB value or even enforce a particular boot drive unit nnn to be stored there.[3] On FAT32 volumes, FreeDOS takes advantage of the DL value as well, whereas it does so on FAT12/FAT16 volumes only, if the BPB value is set to FFh.)
  • DH bit 5 = 0: device supported through INT 13h; else: don't care (should be zero). DH is supported by some IBM BIOSes. Some MBR and VBR codes preserve the value of DH.

Systems with Plug-and-Play BIOS or BBS support will provide a pointer to PnP data in addition to DL:[2][4]

  • DL = boot drive unit (see above)
  • ES:DI = points to "$PnP" installation check structure

This information allows the boot loader (in the MBR or VBR) to actively interact with the BIOS or a resident PnP / BBS overlay in memory in order to configure the boot order etc., however, this information is ignored by most standard MBRs and VBRs. Ideally, ES:DI is passed on, but PnP-enabled operating systems typically also have fallback methods to retrieve the PnP BIOS entry point later on so that most operating systems do not rely on this. Information in ES:DI can be used as a hint - according to the PnP BIOS specification, "$PnP" installation check structure could be found by searching for a signature of the ASCII string $PnP in system memory starting from F0000h to FFFFFh at every 16 byte boundary.

With partitioned media, when the VBR is launched by the MBR (or different boot loader) rather than the BIOS, many implementation pass additional information to the VBR besides just DL (and sometimes DH and ES:DI as well):

  • DS:SI = points to the 16-byte MBR partition table entry (in the relocated MBR) corresponding with the activated VBR. PC-MOS 5.1 depends on this to boot if no partition in the partition table is flagged as bootable. In conjunction with LOADER, Multiuser DOS and REAL/32 boot sectors use this to locate the boot sector of the active partition (or another bootstrap loader like IBMBIO.LDR at a fixed position on disk) if the boot file (LOADER.SYS) could not be found. PTS-DOS 6.5 and S/DOS 1.0 use this in conjunction with their Advanced Active Partition (AAP) feature. In addition to support for LOADER and AAPs, DR-DOS 7.07 can use this to determine the necessary INT 13h access method when using its dual CHS/LBA VBR code. The MBR code of OS/2, MS-DOS (prior to 7.0), PC DOS (up to 7.10), and Windows NT (up to ca. 2007) happens to provide this same interface as well, although these systems do not make use of it. The MBR installed by Windows NT 6.0 (and higher) uses other registers, and is therefore no longer compatible with these extensions. While some extensions only depend on the 16-byte partition table entry itself, other extensions may require the whole 4 (or 5 entry) partition table to be present as well.

Under DR-DOS 7.07 an extended interface may be optionally used by the MBR and in conjunction with LOADER:

  • AX = magic signature indicating the presence of this extension (0EDCh)
  • DL = boot drive unit (see above)
  • DS:SI = points to the 16-byte MBR partition table entry used (see above)
  • ES:BX = start of boot sector or special "NEWLDR" sector image (typically 7C00h)
  • CX = reserved

In conjunction with GUID partition tables (GPT), an Enhanced Disk Drive Specification (EDD) 4 Hybrid MBR proposal recommends another extension to the MBR to VBR interface:[5]

  • EAX = 54504721h ("!GPT")
  • DL = boot drive unit (see above)
  • ES:DI = points to "$PnP" installation check structure (see above)
  • DS:SI = points to a Hybrid MBR handover structure, consisting of a 16-byte dummy MBR partition table entry (with all bits set except for the boot flag at offset +0h and the partition type at offset +4h) followed by additional data. This is partially compatible with the older DS:SI extension discussed above, if only the 16-byte partition entry, not the whole partition table is required by these older extensions.

See also

[edit]

Notes

[edit]

References

[edit]

Further reading

[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Volume boot record

View on Grokipedia
from Grokipedia
A volume boot record (VBR), also known as a , is the first logical sector (typically 512 bytes) of a partitioned device, such as a or , that contains executable bootstrap and file system parameters essential for loading an operating system from the associated partition. Unlike the (MBR), which resides at the start of the entire disk and identifies active partitions, the VBR is specific to an individual partition and is invoked by the MBR or boot manager to initiate the boot process for that volume. It plays a crucial role in the chain-loading mechanism of legacy BIOS-based systems, where loads the VBR into and transfers control to its , enabling the system to recognize the file system layout and proceed to load the OS kernel. The VBR structure varies by but generally includes a jump instruction to the bootstrap code, a (BPB) with metadata such as bytes per sector, sectors per cluster, and volume size, a file system type identifier, a volume serial number and label, and a boot signature (commonly 0xAA55 at the end) to validate the sector's integrity. In the FAT family of file systems (including FAT12, FAT16, and FAT32), the VBR defines the reserved area, FAT locations, and cluster, with backups providing copies for recovery, facilitating access to the for OS loading. For , an extension of FAT32, the VBR includes similar fields plus allocations for the volume bitmap and upcase table to support larger volumes and filenames. In Microsoft's NTFS, the VBR, which is the first sector of the $Boot system file, provides boot code alongside critical volume geometry, such as the logical cluster number (LCN) of the master file table (MFT), clusters per file record, and total sectors, ensuring reliable initialization and supporting features like journaling for data integrity. A backup VBR is typically maintained at a fixed offset (e.g., sector 6 in FAT32 or near the end of the volume in NTFS) to aid recovery from corruption, which can render the volume unbootable if the primary fails. While modern UEFI systems often bypass VBRs in favor of GUID Partition Table (GPT) and EFI boot loaders, VBRs remain relevant for compatibility with legacy BIOS booting and in forensic analysis of storage media.

Introduction

Definition and purpose

A volume boot record (VBR), also known as a partition boot sector or boot sector, is the first logical sector of a data storage volume, containing executable code to initiate the operating system boot process. This sector serves as the entry point for booting from the volume, whether it is a partition on a larger storage device or an entire unpartitioned medium. The primary purpose of the VBR is to provide a bootstrap loader that detects the underlying , loads the operating system kernel or a secondary boot loader, and manages basic drive geometry parameters necessary for accessing the volume. It plays a crucial role in the boot chain by enabling the to recognize and mount the volume's structure, ensuring compatibility across various storage media such as hard disks and floppy disks. Without a functional VBR, the boot process cannot proceed to load the operating system from that volume. Key characteristics of the VBR in legacy BIOS-based systems include a standard size of 512 bytes and an assumption of x86 architecture operating in , which facilitates direct execution by the during initialization. This design ensures efficient handover from the system's basic input/output system () to the volume's boot code.

Relation to master boot record

The (MBR) resides in the first sector (sector 0) of a storage device such as a , occupying 512 bytes and consisting of executable bootstrap code, a partition table with up to four primary partition entries (each 16 bytes), and a boot (0xAA55 at the end). This structure enables the MBR to serve as the initial in the boot sequence for partitioned devices, where the loads the MBR into memory at address 0x7C00 and transfers control to its bootstrap code. In the delegation process on partitioned volumes, the MBR's bootstrap code scans the partition table to locate the active (bootable) partition, identified by a boot indicator byte of 0x80 in the corresponding entry. It then uses BIOS disk services (via interrupt 13h) to read the first sector of that partition—the volume boot record (VBR)—into memory at 0x7C00, overwriting the MBR, and jumps to it to continue the boot chain. This handoff positions the VBR to handle file system-specific bootstrapping, such as loading the operating system kernel from the active volume. In contrast, on unpartitioned devices like floppy disks, no MBR exists; the BIOS directly loads the VBR from the device's first bootable sector (typically sector 1) without partition selection. Key differences highlight the distinct scopes of the MBR and VBR: the MBR operates at level, providing global partition management independent of any or operating system, while the VBR functions at the volume level, specific to a single partition and tailored to its for OS loading. Additionally, the MBR's partition table uses 32-bit (LBA), imposing a maximum addressable disk size of 2^32 sectors (approximately 2 TiB at 512 bytes per sector), a limitation that does not directly constrain the VBR but affects overall device partitioning.

Historical development

Origins in IBM PC and MS-DOS

The volume boot record (VBR) emerged with the introduction of the IBM Personal Computer (Model 5150) in August 1981, which utilized a BIOS-based booting mechanism to initialize the system from floppy disk media. The IBM PC's ROM BIOS, through Interrupt 19h, loaded the first sector (Track 0, Head 0, Sector 1) of the bootable floppy disk into memory at physical address 0000:7C00h, where it executed as the initial boot code. This sector, comprising 512 bytes, contained assembly language instructions designed to search the root directory for essential system files and load them into memory, marking the foundational role of the VBR in personal computing boot processes. The design was tailored for the PC's 5.25-inch floppy drives, supporting single-sided 160 KB disks formatted with an 8-sector-per-track geometry. In conjunction with the IBM PC, Microsoft supplied MS-DOS 1.0 (branded as PC-DOS 1.0 by IBM), where the VBR played a central role in the boot sequence by verifying the presence of the device driver file IBMBIO.COM (equivalent to IO.SYS in generic MS-DOS) and the system kernel IBMDOS.COM (MSDOS.SYS). Upon execution at 7C00h, the VBR code initialized registers, checked for a valid floppy disk insertion, and scanned the root directory for these contiguous files, loading them starting at memory location 0000:0600h if found. If the disk was non-system, the VBR displayed an error message such as "Non-System disk or disk error" and prompted for disk replacement, halting further progress until resolved. This simple, self-contained VBR lacked a formalized BIOS Parameter Block (BPB) or end-of-sector signature, relying instead on hardcoded assumptions about disk geometry and file locations to complete the load of COMMAND.COM, the command interpreter, thereby transitioning to the DOS user environment. The VBR's development was heavily influenced by the IBM PC's BIOS Interrupt 13h, which provided low-level disk access functions for reading sectors via cylinder-head-sector (CHS) addressing, enabling the VBR code to interact with floppy hardware during file loading. Early implementations in MS-DOS 1.0 exhibited variations due to the absence of a comprehensive specification, with customizations for IBM's hardware and limited error recovery (up to four read retries per sector). Standardization advanced with PC-DOS 2.0 in March 1983, which extended VBR usage to hard disks via partitioned media while formalizing the 512-byte sector size across floppy and fixed-disk contexts, alongside the adoption of the FAT12 file allocation table for consistent volume management. This evolution addressed initial inconsistencies, ensuring broader compatibility as the platform matured.

Evolution in Windows and other systems

The Volume Boot Record (VBR) underwent significant adaptations starting with the Windows NT era, where the introduction of the New Technology File System () in 1993 with necessitated an extended VBR structure to accommodate larger volume sizes beyond the limitations of earlier FAT-based systems. Unlike the 32-bit sector count in FAT's (BPB), the NTFS VBR incorporated a 64-bit Total Sectors field, enabling support for volumes up to 16 exabytes in theory, though practical limits were set by hardware and software at the time. In this boot process, the VBR code chain-loaded the boot loader from the root directory of the active partition, marking a shift from the direct loading mechanisms of MS-DOS-style systems and providing greater flexibility for multi-boot environments. A key milestone in VBR evolution came in 1996 with the FAT32 extensions, integrated into OEM Service Release 2, which expanded the BPB to use 28-bit FAT entries and a 32-bit sector count, allowing partitions larger than 2 GiB—up to 2 TiB in practice—and addressing the growing needs of larger hard drives. This update retained backward compatibility with FAT16 while enhancing the VBR's jump instruction and BPB fields to handle the increased , ensuring seamless booting on legacy systems. From in 2007 onward, the boot architecture evolved further with the adoption of the (BOOTMGR) and WINLOAD.EXE, which diminished the VBR's direct executable role in the primary boot path but preserved it for partition-specific initialization and compatibility with legacy modes. In this setup, the VBR still executed first to load BOOTMGR from the root of the boot volume, after which BOOTMGR handled the Boot Configuration Data (BCD) and Secure Boot precursors like early integrity checks, reducing reliance on VBR bootstrap code for complex operations. The VBR's BPB was updated to include flags for these extended boot features, maintaining across Windows versions. In 2006, introduced with Windows CE 6.0, featuring a simplified BPB in the VBR tailored for flash media like USB drives and SD cards, which omitted legacy compatibility fields and used shift-based encoding for bytes per sector and clusters to minimize overhead on non-rotational storage. This design supported volumes up to 128 petabytes and files larger than 4 GiB without the fragmentation issues of FAT32, while the VBR's OEM parameters allowed flash-specific optimizations like erase block alignment. Beyond Windows, adaptations of VBR-like mechanisms appeared in other systems, though often with platform-specific variations. In , the GRUB bootloader's stage 1.5 utilized sectors resembling a VBR to embed filesystem drivers for and , enabling it to read and load subsequent stages like the full GRUB configuration from the /boot partition without requiring full kernel intervention. Conversely, macOS's HFS+ volumes, formatted under the (APM), employed a Volume Header at a 1024-byte offset rather than a traditional single-sector VBR, limiting direct VBR usage to blocks reserved for legacy compatibility and relying on the startup file for non-Mac OS . The transition to across systems did not overhaul the VBR itself, which remained essential only for legacy BIOS , as firmware directly accessed files instead of chain-loading via VBR.

Structure

General layout

The volume boot record (VBR) comprises a fixed 512-byte sector that integrates executable boot code, file system parameters, and validation elements to enable volume bootstrapping. This structure assumes a standard sector size of 512 bytes, with provisions in the parameters for verifying larger logical sectors and handling discrepancies accordingly. The sector opens with boot code at offsets 0–2, consisting of a 3-byte x86 jump instruction (such as EB 3C 90) that skips to the main , followed by optional OEM data at offsets 3–10—an 8-byte identifier for compatibility (e.g., "MSWIN4.0"). The (BPB) integrates at offsets 11–53 (or extended to 90 in some variants), embedding critical volume metadata like bytes per sector and sectors per cluster to guide access. The bulk of the boot code occupies the space following the BPB up to offset 509 (typically 400-450 bytes depending on the BPB size), implemented as compact x86 assembly that initializes the processor stack, interrogates the via BPB values, and transfers control to the OS loader. Offsets 510–511 conclude the sector with a mandatory 2-byte signature of 0x55 followed by 0xAA (little-endian representation of 0xAA55), affirming the sector's validity as a boot record. Preceding bytes, if unused by boot code, are typically padded with 0x00 to maintain alignment and prevent execution artifacts.

BIOS Parameter Block

The BIOS Parameter Block (BPB) is a data structure embedded within the volume boot record (VBR) that provides essential metadata about the physical and logical layout of the storage volume, enabling the boot code to interpret and access the file system without predefined knowledge of its configuration. Positioned starting at offset 11 and extending to offset 62 for the standard BPB (with an optional extended BPB up to offset 90 in FAT32), it includes parameters such as bytes per sector—typically 512 for compatibility with BIOS-based systems—and sectors per cluster, which defines the allocation unit size as a power of 2 (e.g., 1, 2, 4, 8, 16, 32, 64, or 128 sectors). These fields, along with reserved sector count, number of file allocation tables (FATs, usually 2), and FAT size in sectors, allow the boot loader to compute critical locations like the start of the FAT (after reserved sectors) and the data region. Core fields in the BPB begin after the initial jump instruction to boot code (offsets 0-2, typically EB 3E 90h) and OEM name (offsets 3-10, an 8-byte ASCII identifier like "MSWIN4.1"). Key parameters include sectors per track and number of heads (used for legacy geometry), hidden sectors (representing the offset from the start of the disk to the partition), and total sectors (either 16-bit or 32-bit for larger volumes). The media descriptor byte further indicates the volume type (e.g., 0xF8 for fixed hard disks). These elements ensure the boot code can perform disk I/O via interrupt 0x13, which relies on the provided geometry to read sectors correctly during the loading process. For FAT16 and FAT32 file systems, an extended BPB (EBPB) follows the standard fields, adding specifics like file system version (typically 0.0), root directory cluster number (usually 2 for FAT32), and sector locations for FSInfo structures or backup boot sectors. In NTFS, the BPB is minimally utilized with core fields like bytes per sector, sectors per cluster, and hidden sectors, but the extended portion shifts focus to NTFS-specific metadata such as the logical cluster number of the Master File Table (MFT, often at cluster 0 but relocatable) and clusters per file record segment. This optional extended use in NTFS supports flexible MFT placement for reliability, while still providing the foundational parameters for boot code execution. The following table summarizes selected fields in the BPB as primarily used in FAT file systems (field positions are similar in NTFS, but values and usage often differ):
Offset (hex)Size (bytes)Field NameDescription
0B2Bytes Per SectorNumber of bytes in a sector (e.g., 512).
0D1Sectors Per ClusterAllocation unit in sectors (power of 2).
0E2Reserved SectorsCount of reserved sectors at volume start (at least 1).
101Number of FATsNumber of FATs (typically 2 in FAT for redundancy; 0 in NTFS).
151Media DescriptorVolume type (e.g., 0xF8 for hard disks).
182Sectors Per TrackGeometry for BIOS INT 13h (legacy).
1A2Number of HeadsGeometry for BIOS INT 13h (legacy).
1C4Hidden SectorsSectors before the partition start.
204Total Sectors32-bit total logical sectors on the volume.
For FAT32 extended fields (offsets 24-5B hex), examples include FAT size in sectors (4 bytes), root cluster (4 bytes), and FSInfo sector (2 bytes). Overall, the BPB's role is pivotal in bridging hardware access via BIOS interrupts to file system navigation, ensuring robust bootstrapping across compatible volumes.

File system variations

FAT implementations

The Volume Boot Record (VBR) for FAT12 and FAT16 file systems incorporates a (BPB) that defines key parameters for volume access, including the size of each in sectors (BPB_FATSz16 at offset 22, 2 bytes), the maximum number of entries (BPB_RootEntCnt at offset 17, 2 bytes; typically 512 for FAT12 volumes to ensure compatibility), and the media descriptor (BPB_Media at offset 21, 1 byte; 0xF8 commonly used for hard disks). These fields enable the boot code to locate and interpret the volume's structure, with the fixed in size and position immediately following the FATs. The media descriptor also influences handling for disk I/O, while the drive number field (BS_DrvNum at offset 36, 1 byte; 0x80 for fixed drives) specifies the boot device for calls. The boot code within the FAT12 and FAT16 VBR, executed after the jump instruction at offset 0, calculates the root directory's starting sector using the reserved sector count (BPB_RsvdSecCnt at offset 14), the number of FATs (BPB_NumFATs at offset 16), and the FAT size. It then loads the root directory sectors into (typically at 0x7C00 or higher) and scans the 32-byte directory entries for the system loader files, such as IO.SYS on PC-DOS or MSDOS.SYS on , before loading the selected file's clusters via FAT chain traversal and transferring control to it. A representative outline for this process in FAT12/FAT16 is as follows:

Read BPB from sector 0 into memory. root_dir_sectors = (BPB_RootEntCnt * 32 + BPB_BytsPerSec - 1) / BPB_BytsPerSec root_dir_start = BPB_RsvdSecCnt + (BPB_NumFATs * BPB_FATSz16) Load root_dir_start to root_dir_start + root_dir_sectors - 1 into memory buffer. For each 32-byte entry in buffer: If entry matches "IO SYS" or "MSDOS SYS" (padded, uppercase) and attributes indicate [executable](/page/Executable): file_start_cluster = entry's first cluster field. Load clusters starting from file_start_cluster (via [FAT](/page/Fat) reads) into 0x7000. Jump to 0x7000. If no match, halt or display error.

Read BPB from sector 0 into memory. root_dir_sectors = (BPB_RootEntCnt * 32 + BPB_BytsPerSec - 1) / BPB_BytsPerSec root_dir_start = BPB_RsvdSecCnt + (BPB_NumFATs * BPB_FATSz16) Load root_dir_start to root_dir_start + root_dir_sectors - 1 into memory buffer. For each 32-byte entry in buffer: If entry matches "IO SYS" or "MSDOS SYS" (padded, uppercase) and attributes indicate [executable](/page/Executable): file_start_cluster = entry's first cluster field. Load clusters starting from file_start_cluster (via [FAT](/page/Fat) reads) into 0x7000. Jump to 0x7000. If no match, halt or display error.

FAT32 extends the VBR with an Extended BPB (EBPB) to support larger volumes, introducing fields such as the 32-bit FAT size in sectors (BPB_FATSz32 at offset 36, 4 bytes), the first cluster number of the (BPB_RootClus at offset 44, 4 bytes; usually 2, treating the root as a chain of clusters rather than a fixed region), the location of the FSInfo (BPB_FSInfo at offset 48, 2 bytes; typically sector 1, with a at sector 6 for recovery), and the type string (BS_FilSysType at offset 82, 8 bytes; "FAT32 "). The FSInfo sector stores free cluster counts and the next available cluster for efficient allocation during . This design enables FAT32 to address volumes exceeding 2 TiB through 28-bit cluster numbering in each 32-bit FAT entry (with 4 bits reserved for status flags), allowing up to approximately 268 million clusters depending on cluster size. FAT32 VBRs maintain with FAT12 and FAT16 interpreters by populating legacy BPB fields appropriately and using the same 0x55AA signature at offset 510, ensuring older bootloaders can recognize the volume even if they cannot fully utilize it. This compatibility facilitated the evolution toward for even larger and more efficient storage, though exFAT introduces distinct VBR structures.
FieldOffset (FAT12/16)Offset (FAT32)DescriptionExample Value
BPB_Media2121Media type descriptor0xF0 (removable), 0xF8 (fixed)
BS_DrvNum3664BIOS drive number0x80 (fixed disk)
BPB_FATSz16/322236Sectors per FATVaries by volume size
BPB_RootEntCnt1717 (set to 0)Root entries (FAT12/16 only)512
BPB_RootClusN/A44Root first cluster (FAT32 only)2
BPB_FSInfoN/A48FSInfo sector1 (backup at 6)
BS_FilSysType5482File system type"FAT12 ", "FAT16 ", "FAT32 "

NTFS and exFAT

The NTFS Volume Boot Record (VBR) contains a minimal BIOS Parameter Block (BPB) that specifies key parameters such as sectors per cluster, the starting cluster number of the Master File Table (MFT), and total sectors. This BPB is followed by bootstrap code that locates and loads the boot manager (bootmgr) in Windows Vista and later systems or the NT Loader (NTLDR) in Windows NT/2000/XP, enabling the system to access the MFT for further boot operations. The VBR structure includes an 8-byte Volume UUID at offsets 72–79 for unique volume identification and a 4-byte checksum at offset 80 to verify the integrity of the boot sector data. NTFS volumes can scale up to 16 exabytes in size, facilitated by 64-bit Logical Cluster Numbers (LCNs) that allow addressing of vast numbers of clusters without the limitations of earlier 32-bit schemes. For fault tolerance, NTFS maintains a backup copy of the boot sector at the end of the volume (the last sector of the partition) within the $Boot metadata file, which spans the first 16 sectors of the volume. The VBR employs a simplified BPB. The locations of the allocation bitmap and up-case table are specified in dedicated directory entries in the , which are essential for managing cluster allocation and case-insensitive handling without a traditional . The OEM identifier in the BPB is fixed as "EXFAT " ( in ASCII followed by three spaces), distinguishing it from other file systems. The bootstrap code within the VBR, occupying 390 bytes, executes a jump instruction to load additional boot code starting from cluster 2, which typically serves as the entry point. Designed for flash-based storage like SSDs and USB drives, optimizes performance by replacing the table with a compact allocation bitmap, reducing metadata overhead and on non-volatile media. Key differences between and VBRs lie in their architectural priorities: emphasizes robust MFT bootstrapping with integrated redundancy for enterprise reliability, while streamlines the structure by omitting root directory entries from the VBR and using compact 32-byte directory entries to support efficient large-file operations on . The VBR includes a cluster heap offset field in its BPB, enabling support for volumes exceeding 128 petabytes by leveraging 64-bit addressing for the entire volume length.

Invocation and execution

Loading process

The loading of the volume boot record (VBR) begins with firmware initiation during system startup. In legacy BIOS mode, following the Power-On Self-Test (POST), the firmware scans boot devices in priority order and uses interrupt 13h (INT 13h) with function AH=02h to read the initial boot sector into memory at physical address 0000:7C00h. For unpartitioned media, such as floppy disks or non-partitioned volumes, this directly loads the VBR from logical sector 0 (cylinder 0, head 0, sector 1), transferring 512 bytes via parameters specifying the drive (DL register), geometry (CH, CL, DH registers), sector count (AL register), and buffer address (ES:BX registers). The process relies on programmed I/O (PIO) mode, with the BIOS handling error correction for up to 5-bit errors per sector. For partitioned disks using a master boot record (MBR), the firmware first loads the MBR from the disk's sector 0 into memory at 0000:7C00h using the same INT 13h AH=02h call. The MBR code then parses its embedded partition table, located at offsets 446 to 509 (1BEh to 1FDh), consisting of four 16-byte entries. It identifies the active (bootable) partition by checking the boot indicator byte at the start of each entry (value 80h denotes active), typically the first such entry found. The starting logical block address (LBA) of the active partition is derived from the relative sectors field (a 4-byte little-endian value at offset 6 within the entry, representing sectors from the disk start). Using this LBA, converted to CHS addressing if needed, the MBR issues another INT 13h AH=02h call to read 512 bytes from the partition's first sector—the VBR—into memory, often at the same 0000:7C00h location after saving prior state. In systems with boot managers, the loading process may be extended while preserving the VBR as the volume-specific entry point. For GRUB in legacy mode, the MBR contains GRUB's stage 1 code, which loads subsequent stages (e.g., stage 1.5 in the post-MBR gap) and can chainload the VBR of a selected partition to initiate the target operating system's boot sequence. Similarly, the Windows VBR, after loading, transfers control to bootmgr.exe (the ) in the root of the system partition, which manages multi-boot options but relies on the VBR as the initial partition loader. In firmware operating in Compatibility Support Module (CSM) or legacy mode, the process mirrors behavior, with the firmware emulating calls for disk access. Error handling occurs if the loading fails or the sector is invalid. If no active partition is marked in the MBR table or the read operation returns a non-zero status in AH (e.g., due to media errors or geometry mismatches), the BIOS routine invoked via INT 19h (bootstrap loader) terminates with a "Non-system disk or disk error; replace and press any key when ready" message, prompting user intervention. Additionally, even if loaded successfully, the BIOS or MBR code verifies the VBR's boot signature (bytes 55h AA at offsets 510-511); an invalid signature triggers the same error and halts the process.

Runtime environment and limitations

Upon loading, the volume boot record (VBR) is placed into physical memory at address 0000:7C00h in segment:offset notation by the or . The DL register is configured to indicate the boot unit, with a value of 0x00 for floppy drives and 0x80 for hard disk drives, while other registers retain their BIOS-default values or are zeroed as needed by the boot . Execution begins immediately as the CPU performs a jump to 0000:7C00h, entering where the VBR must initialize essential components without relying on prior setup. The VBR boot code typically establishes data and extra segment registers (DS and ES) to 0 for flat addressing in the low 1 MB of , and configures the stack pointer (SP) to point downward from 7C00h to provide a small stack area within the available space below the data areas. To determine the extent of , the code often invokes interrupt INT 12h, which returns the available RAM size in kilobytes (up to 640 KB) in the AX register, allowing the boot process to avoid overflows when loading subsequent stages. This setup operates exclusively in , restricting direct access to above 1 MB and prohibiting features until a secondary loader transitions the system. Key limitations constrain VBR functionality: the entire record fits within a single 512-byte sector, leaving limited space for executable code after accounting for the and boot signature, typically under 400 bytes for logic. It supports no multitasking or advanced OS services, relying solely on interrupts for I/O, and assumes standard 512-byte sector sizes, which can fail on advanced storage with larger native sectors. Additionally, the VBR is susceptible to corruption by viruses that overwrite its code during infection, potentially rendering the volume unbootable without specialized recovery tools. After completing its tasks, such as loading a secondary boot loader or kernel image into , the VBR transfers control via a far jump to the of the next stage, for example, to in Windows systems after intermediate loaders like bootmgr and winload.

References

  1. https://www.cs.cmu.edu/~410-s07/p4/p4-boot.pdf
  2. https://wiki.osdev.org/Volume_Boot_Record
  3. http://web.cs.ucla.edu/classes/winter13/cs111/scribe/2b/
  4. https://cislinux2.washburn.edu/zzmech/cm203/units/Unit10-TheFAT32FileSystem.pdf
  5. https://events.static.linuxfound.org/images/stories/pdf/lceu11_munegowda_s.pdf
  6. https://dubeyko.com/development/FileSystems/NTFS/ntfsdoc.pdf
  7. https://www.cgsecurity.org/wiki/Advanced_NTFS_Boot_and_MFT_Repair
  8. https://www.r-studio.com/What-is-Boot-Record.html
  9. https://learn.microsoft.com/en-us/windows/win32/fileio/exfat-specification
  10. https://www.cs.fsu.edu/~cop4610t/assignments/project3/spec/fatspec.pdf
  11. https://wiki.osdev.org/MBR_(x86)
  12. https://www.ibm.com/support/pages/operating-systems-using-mbr-have-2-terabyte-2-tb-disk-limitation-ibm-bladecenter-and-system-x
  13. https://bitsavers.org/pdf/ibm/pc/pc/6025008_PC_Technical_Reference_Aug81.pdf
  14. https://www.os2museum.com/wp/dos/dos-1-0-and-1-1/
  15. https://thestarman.pcministry.com/DOS/ibm100/Boot.htm
  16. http://ntfs.com/ntfs-partition-boot-sector.htm
  17. https://www.proteansec.com/reverse-engineering/windows-booting-process/
  18. https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/fatgen103.doc
  19. https://www.microsoftpressstore.com/articles/article.aspx?p=2201310
  20. https://www.gnu.org/software/grub/manual/grub/grub.html
  21. https://developer.apple.com/library/archive/technotes/tn/tn1150.html
  22. https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/boot-to-uefi-mode-or-legacy-bios-mode?view=windows-11
  23. https://academy.cba.mit.edu/classes/networking_communications/SD/FAT.pdf
  24. https://bitsavers.org/pdf/ibm/pc/at/1502494_PC_AT_Technical_Reference_Mar84.pdf
  25. https://www.gnu.org/software/grub/manual/grub/html_node/BIOS-installation.html
  26. https://learn.microsoft.com/en-us/windows-hardware/drivers/devtest/boot-options-in-windows
  27. https://wiki.osdev.org/Boot_Sequence
  28. https://wiki.osdev.org/Real_Mode
  29. https://usa.kaspersky.com/resource-center/definitions/boot-sector-virus
  30. https://thestarman.pcministry.com/asm/mbr/W8VBR.htm
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.