MBR (Master Boot Record)

The Master Boot Record was introduced in March 1983 with PC DOS 2.0 to support the 10 MB hard disk of the IBM PC XT. The original MBR code was written by David Litton of IBM in June 1982. Before that, IBM PCs only handled diskettes, which didn’t need partitioning. The 10 MB hard drive was so big at the time that IBM decided users needed a way to divide it into smaller logical sections, and the MBR was the mechanism. The fundamental design has stayed essentially unchanged for over 40 years.¹

The defining property of MBR is its location and size: the first sector of the disk, exactly 512 bytes. That single sector has to hold the bootloader code that the BIOS will execute, the partition table that describes the disk layout, and a signature that proves the sector is a valid MBR. This is a tight budget, and the design choices it forced (4-partition limit, 32-bit LBA, single point of failure) have shaped 40 years of PC computing.

The boot process step by step

When a PC with BIOS firmware powers on, the boot process follows a fixed sequence:²

1. Power-on self-test (POST). The BIOS checks that essential hardware (CPU, RAM, storage controllers) is functioning.
2. Boot device selection. The BIOS reads its boot order list and tries each device in turn. For each device, it reads the first sector and checks it for an MBR.
3. MBR signature validation. The BIOS reads bytes 510 and 511 of the first sector. If they equal 0x55 and 0xAA (in that order), the sector is a valid MBR. If not, the BIOS moves to the next device.
4. MBR code execution. The BIOS loads the 512-byte MBR into RAM at memory address 0x7C00 and jumps to that address to start executing the MBR’s bootloader code.
5. Partition scanning. The bootloader code reads the partition table at offsets 446-509, looks for the partition with the active (bootable) flag set, and finds its starting sector.
6. Volume Boot Record loading. The MBR code reads the first sector of the active partition (the Volume Boot Record, or VBR) into RAM and transfers control to it.
7. OS bootloader takes over. The VBR contains OS-specific bootloader code (Windows BOOTMGR, GRUB, etc.) that loads the actual operating system kernel.

The 0x55AA signature

This 2-byte signature at the very end of the MBR is what the BIOS specifically checks. If the bytes don’t equal 0x55 followed by 0xAA, the sector is not recognized as an MBR and the BIOS reports something like “Operating System not found” or “Missing operating system.” The signature is not a checksum; it’s just a magic number that says “this is intended to be an MBR.” Any 512-byte sector with these two bytes at the end is a valid MBR by definition, even if its bootloader code or partition table are nonsense.³

CHS to LBA: a brief addressing detour

MBR’s partition table entries originally used Cylinder-Head-Sector (CHS) addressing, a 1980s scheme for identifying disk locations as a triplet (cylinder number, head number, sector number) reflecting the physical geometry of the drive platters. CHS imposed hard limits at 8 GB total disk size. Modern MBR uses Logical Block Addressing (LBA) instead, treating the disk as a flat sequence of 512-byte blocks numbered from 0. The partition entries still contain the legacy CHS fields for backward compatibility, but operating systems ignore them and use the LBA fields. The 32-bit LBA in MBR partition entries is what creates the 2 TB limit (2^32 × 512 bytes = 2 TiB).

The disk signature

Modern MBRs include a 4-byte disk signature at offset 440-443, introduced by Windows NT 3.5. This is a unique random value identifying the specific disk; Linux uses it for the same purpose since kernel 2.6. The disk signature lets the OS distinguish multiple disks reliably, even when they’re connected to different controllers or in different physical positions. It’s separate from the boot signature and serves a different purpose.⁴

The 512-byte MBR has fixed offsets that haven’t changed since 1983. Every MBR-aware tool reads the same byte positions, which is what makes MBR universally compatible across operating systems and decades.⁵

1. Master Boot Code (446 bytes)

The first 446 bytes hold executable code that the BIOS loads into RAM and runs. This code is the bootloader: small, machine-language instructions that scan the partition table for the active partition and chain-load its Volume Boot Record. The exact code differs between operating systems (Windows MBR code is different from Linux GRUB stage 1, which is different from FreeBSD’s, etc.), but the function is the same. Modern MBRs typically include code that prints a brief error message (“Invalid partition table” or similar) when the active partition can’t be found.

The 446-byte budget is tiny. Modern bootloaders do anything sophisticated by chain-loading subsequent stages from the active partition’s VBR or from dedicated bootloader files. The MBR itself just gets the boot process started.

2. Disk Partition Table (64 bytes)

The 64 bytes at offset 446 hold exactly 4 partition entries, each 16 bytes. Every entry has the same format:⁶

• Byte 0: Status / boot flag. 0x80 means active (bootable), 0x00 means inactive. Only one partition should be marked active.
• Bytes 1-3: Starting CHS address. Legacy field, ignored by modern systems.
• Byte 4: Partition type code. A 1-byte identifier of what’s in the partition. Common values: 0x07 for NTFS / exFAT, 0x0B for FAT32 (CHS), 0x0C for FAT32 (LBA), 0x83 for Linux native, 0x82 for Linux swap, 0x05 or 0x0F for extended partition, 0xEE for the protective MBR of a GPT disk.
• Bytes 5-7: Ending CHS address. Legacy field, ignored.
• Bytes 8-11: Starting LBA (32-bit). The first 512-byte sector of this partition.
• Bytes 12-15: Number of sectors (32-bit). The partition’s size in 512-byte sectors.

The 4-entry limit is structural: 64 bytes ÷ 16 bytes per entry = 4. To exceed this, MBR uses extended partitions.

Extended partitions and the EBR chain

To work around the 4-primary-partition limit, MBR allows one of the four primary entries to be marked as an “extended partition” (type 0x05 or 0x0F). The extended partition itself doesn’t hold data; it’s a container for any number of logical partitions. Each logical partition starts with its own Extended Boot Record (EBR), a 512-byte structure similar to the MBR but with a different purpose: it points to the logical partition’s data and to the next EBR in the chain. The EBRs form a linked list inside the extended partition, allowing many more logical partitions than the 4-primary limit would suggest.

The recovery implication: if the extended partition entry in the MBR is damaged, all the logical partitions inside become inaccessible, even though their data is still on disk. TestDisk recovery searches for EBR signatures the same way it searches for partition boot signatures, and can rebuild the EBR chain when the extended partition entry is intact but EBRs themselves are damaged.

3. Boot Signature (2 bytes)

The last 2 bytes (offsets 510-511) must equal 0x55 and 0xAA respectively (often called “0x55AA”). This is the BIOS’s first check; without it, the BIOS doesn’t even attempt to execute the bootloader code. Many MBR damage scenarios involve this signature being lost, which makes the disk appear non-bootable even when everything else in the MBR is intact. Recovery tools can rewrite the signature in seconds.⁷

The Partition entry covers this comparison at a high level, and the GPT entry deep-dives on GPT’s structure. Here’s the comparison from MBR’s perspective with recovery in mind.⁸

When MBR is still the right choice

MBR’s continued use in 2026 is increasingly narrow but real:

• Legacy systems with BIOS-only firmware that cannot boot from GPT. Most pre-2012 PCs fall into this category, plus some industrial and embedded systems built well into the 2010s for specific applications.
• Bootable USB sticks for legacy systems. A USB drive intended to boot Windows XP, old Linux distributions, or legacy diagnostic tools needs MBR because that’s what the target firmware expects.
• Specific embedded systems and industrial controllers. Many programmable logic controllers, point-of-sale terminals, and industrial PCs from before 2018 use MBR exclusively. Replacing them requires verified compatibility.
• Some specialized recovery USBs. The Ultimate Boot CD, older Hiren’s BootCD versions, and other multi-purpose recovery toolkits use MBR for maximum compatibility with diverse target systems.

For everything else (new PCs, new external drives, new USB sticks for modern use, anything over 2 TB), GPT is the right choice in 2026. Modern Windows, macOS, and Linux all default to GPT, and the redundancy plus integrity checks make GPT meaningfully safer for both data and recovery.

MBR’s lack of redundancy means every form of MBR damage is potentially catastrophic, but the failure modes are well understood and most are recoverable with the right tools. Watch for these scenarios.⁹

• Boot signature corruption (0x55AA wiped). The last 2 bytes of the MBR are damaged or zeroed. The BIOS reports “Operating system not found,” “Missing operating system,” or similar. The bootloader code and partition table may be intact; only the signature needs to be restored. bootrec /fixmbr on Windows or TestDisk’s “MBR Code” option fixes this in seconds.
• Bootloader code damage. The 446-byte boot code is corrupted, often by malware or by a botched bootloader installation. Symptoms: BIOS finds the MBR, runs the code, but the boot fails partway through with messages like “Error loading operating system” or just a blinking cursor. Recovery is to overwrite the boot code with a fresh standard MBR.
• Partition table damage. The 64-byte partition table is overwritten or modified. Symptoms: the disk shows up but partitions are missing, RAW, or wrong sizes. The classic “drive needs to be initialized” prompt in Windows. Recovery: TestDisk scans for file system boot sectors and rebuilds the partition table from what it finds.
• MBR overwritten by a Linux installer. A Linux installation that wasn’t configured to dual-boot with the existing Windows installation has overwritten the MBR with GRUB. Windows no longer boots; Linux does. Recovery: Windows installation media + bootrec /fixmbr restores Windows boot, but you’ll lose GRUB and the dual-boot menu unless you reinstall it.
• MBR ransomware. Petya, NotPetya, and similar ransomware variants specifically target the MBR. They overwrite the boot code with their own that displays a ransom demand and refuses to load Windows. The original MBR is sometimes encrypted and stored elsewhere on disk (recoverable if the malware can be reversed), but most variants destroy the original outright. Recovery requires either paying (not recommended) or accepting the boot code is gone and using TestDisk to find the partitions.¹⁰
• Bad sectors at the start of the disk. Physical bad sectors specifically in sector 0 destroy the MBR. Devastating because there’s no backup. Recovery requires bad-sector-tolerant disk imaging tools (ddrescue, HDD Raw Copy Tool) and metadata reconstruction, often at lab level.
• Disk signature collision. Two disks with the same disk signature (often after cloning) cause Windows to refuse to mount one of them. Reported as “The disk is offline because of policy set by an administrator.” Fixable in Windows Disk Management or with diskpart’s uniqueid disk id=NEWGUID command.
• MBR cloned to too-small destination. Imaging a 500 GB MBR disk to a 250 GB destination produces a partition table claiming partitions extend beyond the destination’s actual size. Some tools handle this gracefully; others corrupt the MBR.
• Hybrid MBR confusion. A disk that should be GPT has both a real MBR (not protective) and GPT structures. Tools may use one or the other and disagree. See the GPT entry for the hybrid MBR section in detail.

Warning signs your MBR is damaged

The error messages from BIOS-level boot failures are often cryptic and similar across different problems. Recognizing the patterns helps:

• “Operating system not found” at boot. Boot signature corruption or missing bootable partition.
• “Missing operating system” at boot. Active partition is marked but unreadable, or boot signature is wrong.
• “Invalid partition table” at boot. Partition table structure is damaged.
• “Error loading operating system” at boot. MBR code ran but couldn’t chain-load the active partition’s VBR.
• “Bootmgr is missing” at boot. MBR successfully chained to the VBR, but the Windows boot manager itself is missing or corrupt. Not strictly an MBR problem.
• System boots to BIOS setup repeatedly instead of from disk. BIOS isn’t finding a valid MBR on any boot device.
• Disk shows up in another computer as RAW or unallocated. Partition table is damaged but the disk is otherwise reachable.
• “The disk is offline because of policy” in Windows. Disk signature collision; clone-related issue.
• Different partition layouts visible from different tools. Indicates partition table corruption where some entries are valid and others aren’t.

MBR repair has two main toolchains: Microsoft’s bootrec.exe for Windows boot scenarios, and TestDisk for cross-platform partition table reconstruction. Both can repair most MBR damage scenarios, with different strengths.¹¹

bootrec on Windows

The bootrec.exe tool is built into Windows installation media and recovery environments. To run it, boot from a Windows USB or recovery drive, choose “Repair your computer,” then “Troubleshoot” then “Advanced options” then “Command Prompt.” The four bootrec switches each handle a specific kind of damage:

The standard repair sequence: run fixmbr first, then fixboot, then rebuildbcd. Important: bootrec /fixmbr does not overwrite the partition table (only the bootloader code), so it’s safe even when the partition table is the only thing intact. The /fixmbr command handles boot signature damage and bootloader code damage; partition table damage requires TestDisk or similar.

TestDisk for partition table reconstruction

TestDisk is the canonical free tool for any partition table recovery scenario, MBR or GPT. The workflow:¹²

1. Boot from a recovery environment (a Linux Live USB like Ubuntu Live or GParted Live, or a Windows recovery USB with TestDisk added). Don’t run TestDisk against the live system disk.
2. Image the disk first with ddrescue or HDD Raw Copy Tool to a separate disk. Run TestDisk against the image, not the original. This is the universal partition recovery rule.
3. Launch TestDisk against the image file or the failing disk’s device path.
4. Choose the partition table type. “Intel/PC partition” for MBR. TestDisk usually auto-detects correctly.
5. Run Quick Search. TestDisk scans the start of the disk for known partition signatures (NTFS boot blocks, FAT32 boot records, ext4 superblocks). Most accidentally-deleted partitions show up within seconds.
6. If Quick Search misses partitions, run Deeper Search. This scans the entire disk for file system signatures, taking hours on large disks but finding partitions that Quick Search missed.
7. Verify partition contents by pressing P to list files. If TestDisk lists the expected files, the partition is recoverable.
8. Mark partitions correctly. Press left/right arrows to toggle each partition’s type: P for primary, L for logical, D for deleted (won’t be recovered), * for primary bootable.
9. Write the new partition table. Only after every partition is marked correctly. TestDisk asks for confirmation; type Y and OK.
10. Optionally fix the boot code. If the MBR boot code is damaged, TestDisk’s “MBR Code” option writes a standard MBR boot code that loads the active partition.

When repairs make things worse

Repair tools should be used carefully because some are destructive even when called “fix” or “repair”:

• fdisk /mbr (DOS / older Windows): Writes a new MBR boot code without touching the partition table. Generally safe.
• bootrec /fixmbr: Same operation in modern Windows. Safe.
• bootrec /fixboot: Writes a new VBR. Can destroy a valid VBR if mistakenly run against a damaged-but-recoverable partition. Be sure the right partition is targeted.
• Disk Management’s “Initialize Disk”: Destroys the existing partition table. Never click this on a disk you want to recover. Always click Cancel.
• Format prompts: Same problem. Format always destroys data. Click Cancel and use recovery tools instead.

MBR advantages and drawbacks

👥 Researched & Reviewed By

Marcus Whitfield

Data Recovery Software Analyst & Senior Writer

All Articles X (Twitter)

Marcus has evaluated data recovery tools for more than six years across Windows, macOS, and Linux, from free utilities to enterprise-grade platforms. He writes the technical reference content on Data Recovery Fix, with particular interest in legacy partition table mechanics and the bootrec / TestDisk recovery toolchain.

B.Sc. Computer Science 6+ years data recovery evaluation Storage layer mechanics

Rachel Dawson

Technical Approver · Data Recovery Engineer

All Articles X (Twitter)

Rachel brings over twelve years of cleanroom data recovery experience, including hands-on MBR partition table reconstruction via TestDisk, MBR ransomware (Petya/NotPetya) recovery, and bad sector remediation in MBR sector 0 scenarios. She validates terminology and ensures published reference content reflects actual lab outcomes.

12+ years data recovery engineering PC-3000 certified MBR / boot sector specialist