VHDX BAT recovery

A damaged VHDX block allocation table can disconnect guest addresses from their stored data.

Dynamic and differencing VHDX files use a block allocation table, or BAT, to describe which payload blocks exist and where they are stored. BAT damage may make a disk appear empty, corrupt, or inconsistent even when many payload blocks remain readable.

Understand the symptom

BAT entries combine allocation state with physical file location.

WHY

What is happening

For each logical block, the BAT records state and a file offset. Differencing disks also track sector bitmaps so reads can fall through to the parent. Recovery must distinguish unallocated, zero, fully present, and partially present states, then correlate candidate offsets with checkpoint lineage and guest structures.

What you may see

Symptoms that change the recovery path.

01

Disk mounts with missing ranges

Files or partitions show holes where BAT entries no longer map valid payload blocks.

02

Checkpoint merge fails

Hyper-V cannot reconcile child allocation or sector-bitmap state with its parent.

03

Virtual disk reports invalid BAT

A checker finds impossible states, overlapping offsets, or locations outside the file.

04

Clone completes but files are corrupt

A converter may substitute zeros for blocks it cannot map.

Protect the source

Actions that can make the situation worse.

01

Rebuilding from file order is unreliable

Dynamic blocks are not guaranteed to appear in guest-address order.

02

Merge writes into the parent

A failed consolidation can contaminate the best remaining base state.

03

Wrong sector-bitmap handling mixes generations

Partially present blocks require reads from both child and parent.

Do this now

Safe steps before evaluation.

01

Shut down the VM

Stop all writes, merges, backups, replication, and automatic recovery tasks.

02

Copy the full checkpoint chain

Keep base and child disks, configuration, logs, exports, and file timestamps.

03

Preserve sparse-file semantics

Use a method that retains full file content and does not normalize holes or truncate ranges.

04

Document the last working state

Record checkpoint names, merge attempts, host version, storage incident, and priority guest data.

NEPFOSYS process

How a data-first evaluation proceeds.

01

BAT-state analysis

NEPFOSYS tests entry ranges, states, alignment, overlap, and sector-bitmap relationships.

02

Payload correlation

Candidate blocks are matched against guest partitions, file systems, and parent-child chronology.

03

Protected extraction

Priority files are recovered from a reconstructed virtual view rather than an edited production chain.

A clear next step

Preserve the original device before another repair or recovery attempt.

Start a case with the exact symptoms, incident timeline, prior attempts, encryption details, and the files that matter most. NEPFOSYS will route the case to the appropriate DFW intake or nationwide mail-in path.

Start with a case review

Questions, answered

What customers ask before starting.

What does the VHDX BAT control?

It maps guest logical blocks to physical locations and states inside dynamic or differencing VHDX files.

Can a fixed VHDX have the same BAT problem?

Fixed disks have different allocation behavior; the exact format and disk type must be confirmed before diagnosis.

Should I merge checkpoints first?

No. Preserve and map the full chain before any operation that writes into a parent disk.

DFW local · Nationwide mail-in

Protect the device. Start with the facts.

Start my recovery case