GPT Header Damage Recovery Test
A GPT header damage recovery test asks whether a surviving backup can reconstruct damaged partition metadata. In the generated sample below, it can—provided the backup header and its entry array validate and describe the intended layout. However, a matching header CRC alone does not establish that the partition table is usable. This experiment calculates seven metadata states, including two counterexamples that pass the header checksum. It then rebuilds the primary GPT from the backup and checks the result against the baseline.
Table of Contents
Research Question and Scope
The question is specific: after a defined change near the beginning of a GPT disk, does the surviving metadata support reconstruction of the original primary GPT?
This controlled, byte-level test constructs GPT metadata in memory, applies defined changes, and validates the resulting checksums, location fields, and reconstruction against an unchanged baseline.
The test evaluates partition-map integrity: whether each GPT copy validates, whether a surviving backup supports reconstruction, and whether the rebuilt metadata matches the baseline. For the field definitions behind the experiment, see the GPT Header structure and CRC32 guide.
Reference Configuration and Assumptions
The reference configuration is a 64 MiB logical disk sample. This compact layout keeps the addresses easy to follow and isolates the effects of changes to the GPT headers and entry arrays.
Parameter | Reference configuration |
Logical capacity | 67,108,864 bytes; 131,072 logical blocks |
Logical block size | 512 bytes |
Partition scheme | GPT revision 1.0; protective MBR |
Header and array sizes | 92-byte headers; 128 entries of 128 bytes each |
Active partition | One Microsoft Basic Data entry named LAB-DATA |
Partition contents | Deterministic byte pattern for whole-range integrity checks |
The Microsoft Basic Data entry describes the partition range and intended use. Its payload follows a deterministic byte pattern, enabling an exact comparison before damage and after reconstruction.
The comparison’s expandable calculation notes give both metadata locations, usable boundaries, and the active partition’s exact extent. All LBAs are relative to the start of this logical disk. The logical block addressing guide explains how to translate them into byte offsets.
Experiment Procedure
The labels S0–S6 identify the seven generated sample states used in the results and the Scenario selector. They are not consecutive damage operations on one disk. S0 is the unchanged reference; S1–S5 each start from an independent copy of S0. Only S6 starts from S3.
All changes were made to disposable generated copies. Do not perform these damage operations on a drive containing needed data.
S0 — Baseline: both GPT copies intact.
Construct the protective MBR, primary and backup headers, and identical entry arrays. Validate the checksums, location fields, array dimensions, and partition bounds. Preserve this unchanged state as the reference for every comparison.
S1 — Primary header byte damaged.
Change the primary header’s first DiskGUID byte at header-relative offset +0x38 from 33 to 32. Leave its stored header CRC unchanged. Keep both arrays, the backup header, and partition contents unchanged. This isolates a header-CRC mismatch.
S2 — Primary header missing.
Replace the 512-byte block at LBA 1 with zeros. Preserve the primary array and the complete backup GPT. Check whether the surviving backup supplies a valid reconstruction source when the primary header has no recognizable signature.
S3 — Primary entry array damaged.
In entry 0 of the primary array at LBA 2, change the name byte at entry-relative offset +0x38 from 4C to 4D, changing L to M. Leave both headers unchanged. This isolates an array-CRC mismatch while the primary header CRC still passes.
S4 — Both headers missing.
Replace the primary and backup header blocks, at LBA 1 and LBA 131071, with zeros. Preserve both entry arrays and the partition contents. This tests the limit of reconstruction when neither valid header survives.
S5 — Backup header copied without adaptation.
Copy the backup header block verbatim to LBA 1. Do not change its location fields or checksum. This checks whether a passing header CRC can coexist with incorrect primary-side addresses.
S6 — Primary GPT rebuilt from S3.
Start with the array damage defined in S3. Restore the primary array from its verified backup, adapt the backup header’s location fields for the primary side, and recalculate its header CRC. Compare the reconstructed metadata byte for byte with S0.
For each state, check the header CRC, array CRC, and location relationships separately. A missing header makes the associated checks unavailable; a matching CRC alone does not establish a valid GPT. Separately compare the entire partition-content range, including its SHA-256, against S0. The pass condition is a consistent GPT layout with the partition-content range preserved.
GPT Header Damage Recovery Test Results
The three rendered views below keep the same header region on screen. Follow the outlined byte at row +0030, column 08—header offset +0x38—and compare the stored and calculated header CRCs. The views render the same sample bytes used in the checksum and reconstruction checks.
Primary GPT corruption test: before damage
The baseline primary header contains 33 at DiskGUID +0x38. Its stored and calculated header CRCs match. The primary array and the backup GPT also validate.
GPT header hex comparison: after one byte changes
S1 changes only that byte from 33 to 32. The stored header CRC remains unchanged, but the calculated CRC differs. The red outline identifies the changed byte, while the shaded checksum bytes show the value that was not updated. The valid backup remains a possible reconstruction source in this defined layout.
Backup GPT header recovery experiment: after reconstruction
The reconstruction adapts the verified backup header for the primary location and recalculates its checksum. The outlined byte returns to 33; the stored and calculated CRCs match again. A full byte comparison confirms that the rebuilt primary metadata equals the baseline. This calculated S1-to-baseline transition is separate from S6, which repairs the array damage below.
Array damage: why a passing header CRC is not enough
S3 changes the first partition-name character from L to M in the entry array. The header bytes remain unchanged, so its CRC passes while the array CRC fails. S6 restores the backup array and rebuilds the primary header, returning the original metadata to the baseline.
The GPT partition entry array guide explains why the name belongs to the array rather than the header.
Failure conditions that change the interpretation
The collapsed scenario table retains the remaining checks. With the primary header missing (S2), the intact backup still supports reconstruction. With both headers missing (S4), no valid header remains as a reconstruction source, even though the defined arrays survive. Finally, copying the backup header verbatim to LBA 1 (S5) preserves its valid CRC but leaves incorrect primary location fields.
These outcomes distinguish a matching checksum from a consistent partition map. A valid reconstruction requires checksums and location relationships to agree with the intended layout.
Use the scenario explorer below to compare all seven states in Hex. Start with S0, then switch between S1–S6 to inspect the primary header and the entry-array excerpt alongside the CRC and location checks. Red marks bytes that differ from S0; green in S6 marks reconstructed fields that match the baseline.
CRC values and all seven scenarios
0x867AACB5 → 0x867AACB50xB0F8E8C0 → 0x21E2966D| Scenario | Header CRC | Array CRC | Location | Backup GPT | Calculated interpretation |
|---|---|---|---|---|---|
| S0 · Baseline | PASS | PASS | PASS | VALID | Both GPT copies validate. |
| S1 · Header bit flip | FAIL | PASS | PASS | VALID | Backup header and array remain usable for reconstruction. |
| S2 · Primary header missing | Unavailable | Unavailable | Unavailable | VALID | Backup header and array remain usable for reconstruction. |
| S3 · Primary array damaged | PASS | FAIL | PASS | VALID | Primary header CRC passes, but its array CRC fails; backup remains valid. |
| S4 · Both headers missing | Unavailable | Unavailable | Unavailable | Missing | No valid header remains; automatic header-to-header reconstruction is unsupported. |
| S5 · Blind backup copy | PASS | PASS | FAIL | VALID | CRC passes, but MyLBA and primary array placement fail. |
| S6 · Rebuilt primary | PASS | PASS | PASS | VALID | Primary GPT equals the baseline; both copies validate. |
Header CRC: 92 bytes with +0x10–+0x13 zeroed. Array CRC: 128 × 128 = 16,384 bytes. Location checks validate MyLBA and primary-array placement. Missing headers make these checks unavailable.
Generated 64 MiB sample · 512-byte blocks · header and entry bytes switch with the scenario; checks are precomputed.
Why the Results Follow from the Mechanism
UEFI 2.11, Section 5.3.2 defines separate header and entry-array checks. The header CRC covers HeaderSize bytes with HeaderCRC32 temporarily zeroed. The array CRC covers NumberOfPartitionEntries × SizeOfPartitionEntry bytes. Location checks add information that neither checksum supplies.
In this sample, S1 changes a header-CRC input. S3 changes an array-CRC input. S5 preserves the header-CRC input but violates the primary location requirements. These controlled differences explain the three distinct validation outcomes shown in the explorer.
The sample also explains why the primary and backup header checksums differ at baseline: their location-dependent fields differ. Identical arrays can share a checksum while their associated headers do not.
Practical Interpretation and Limitations
On a real disk, first preserve the source and identify the correct device by model or serial number, capacity, and logical block size. Perform any proposed metadata writes on a disposable working copy. A USB bridge, a resized image, or a truncated acquisition can change the address context; do not substitute this sample’s last LBA for the actual device boundary.
Next, establish whether a surviving backup describes the intended current layout. A correct CRC detects certain byte changes; it does not prove freshness or authenticity. UEFI specifically warns about stale backup GPT metadata after a disk has been reformatted for legacy MBR use. Conflicting copies require investigation before either is accepted as authoritative.
Microsoft’s Windows and GPT FAQ provides background on GPT redundancy and CRC protection. Recovery behavior depends on the operating system, the tool, and platform policy. Confirm which GPT copy a tool accepts and which metadata ranges it proposes to change before approving a repair.
After metadata reconstruction, confirm the expected partition boundaries, inspect the file system without modifying the source, and verify representative files against known copies where available. For a system disk, follow this with a boot check on the intended target. These checks establish file accessibility and startup readiness after the partition map has been validated.
When File Recovery Comes Before GPT Repair
When a partition disappears or its volume becomes inaccessible, securing important files may take priority over writing changes to the GPT. Magic Data Recovery’s lost-partition workflow can scan for recoverable files, preview supported file types, and save selected data to another drive. After recovering the files you need, assess the partition layout and plan any metadata repair on a working copy. Keep file recovery and GPT reconstruction as separate tasks, with separate checks for recovered files and partition-table integrity.
Conclusion
This GPT header damage recovery test demonstrates how a valid backup can support reconstruction after primary-header corruption or loss. In the tested sample, restoring the entry array and adapting the header’s location fields returned the primary GPT to its baseline bytes. The decisive condition is that the surviving backup header and its associated array both validate and describe the intended partition layout.
The comparisons also show why a passing header CRC32 is insufficient: entry-array damage can leave the header checksum unchanged, while an unmodified backup header can retain a valid checksum at the wrong location. Reliable GPT recovery therefore requires agreement between header checksums, array checksums, and location fields. After reconstruction, verify partition boundaries, file-system access, and important files separately; system disks also need a boot check. A restored partition map establishes metadata consistency, while these additional checks determine whether the disk is usable again.
FAQ About GPT Header Damage and Recovery
How do I check whether a GPT header is damaged?
Can a corrupted GPT header be repaired from the backup?
Does the backup GPT preserve partitions that were deleted?
Can GPT header recovery restore files without data loss?
What if both the primary and backup GPT headers are damaged?
How can I test GPT header recovery safely?
Will repairing a GPT header fix a Windows boot failure?
