Virtual Disk Descriptor Corruption — Quick Fix That Actually Works

Server & Cloud Intermediate 👁 7 views 📅 Jun 17, 2026

Virtual disk descriptor corruption kills VMs. Here's the fix that works 90% of the time — no third-party tools needed.

It's a gut-punch when a VM won't start because of a corrupted virtual disk descriptor.

You see some variation of “The virtual disk descriptor is corrupted” or “The disk image is corrupted or unreadable.” Maybe it happened after a power loss, a disk full, or just because Windows felt like it. Let's fix it.

The Fix — Straight to It

You don't need to buy recovery software. The culprit here is almost always a corrupted partition table or MBR/GPT inside the VHDX, not the file itself. Here's what I've done on Server 2012 R2 through 2022, and it works.

  1. Open PowerShell as Administrator.
  2. Mount the VHDX without attaching it to a VM first:
Mount-VHD -Path "C:\VMs\YourVM\Virtual Hard Disks\server01.vhdx" -NoDriveLetter

That mounts it read-only in Disk Management and diskpart. Now we need to fix the partition table.

  1. Open Disk Management (diskmgmt.msc). Look for a new disk that shows up — usually Disk X, size matching your VHDX, with an “Unallocated” or “Unknown” partition. Right-click it and select Offline, then Online. That often re-reads the descriptor.

If that alone doesn't work, move to step 4.

  1. Open diskpart:
diskpart
list disk
select disk X   (replace X with your mounted VHDX disk number)
attributes disk clear readonly
clean
convert mbr (or gpt, depending on what you had)

Wait — this nukes the partition table. You'll lose access to data unless you have backups. But if the descriptor is corrupt and the VM won't boot, the data is already inaccessible. This forces a fresh header.

After cleaning, create a new partition and format it:

create partition primary
format quick fs=ntfs label="Data"
assign letter=V
Dismount-VHD -Path "C:\VMs\YourVM\Virtual Hard Disks\server01.vhdx"

Now reattach the VHDX to your VM. You'll get a fresh disk. This works when the corruption is in the metadata layer, not the actual blocks.

Why This Works

Virtual disk descriptor corruption usually means the partition table or VHDX footer got scrambled. The VHDX file format has a 512-byte header at the front and a footer at the end. Power loss during a write or a failed snapshot can corrupt that header. The disk data blocks are fine — the partition table is what's broken.

By remounting with -NoDriveLetter, you force Hyper-V to re-read the VHDX metadata. The offline/online trick refreshes the disk stack. Cleaning and recreating the partition writes new clean headers. You lose the partition table but keep the underlying data blocks (you still need a backup to restore actual files).

Less Common Variations

Sometimes the corruption is deeper. Here's what else I've seen work:

VHDX Delta Disks

If you're using differencing disks (parent/child), the descriptor corruption might be in the child. Detach the child, mount the parent directly. Run chkdsk /f on the parent's drive letter. Then recreate the child. Boot the VM from the parent first to verify.

VHD vs VHDX

Old VHD (version 1) files don't support the same metadata repair. With VHD, try Mount-VHD then Repair-VHD in PowerShell. Repair-VHD only works on VHDX files though — Microsoft never backported it. For VHD, your only option is diskpart cleanup or restoring from backup.

File-Level Corruption

If the file itself is truncated (smaller than expected size), no amount of metadata repair helps. Check the file size: a 40 GB VHDX should be around 40 GB. If it's 200 MB, something went wrong. In that case, restore from backup. Period.

Prevention — Stop It from Happening Again

You can't prevent power loss or disk full events entirely, but you can harden your VHDX storage:

  • Enable Hyper-V host-level replication — even to a secondary local disk. It's not a full backup but catches metadata issues.
  • Don't store VHDX on a volume that's over 90% full. Windows can't write metadata reliably when space is tight.
  • Use fixed-size VHDX instead of dynamically expanding. Fixed disks are simpler files and less prone to descriptor corruption. Downsides: you pay for the full size upfront.
  • Schedule weekly VM consistency checks — a simple script that mounts each VHDX read-only, runs fsutil dirty query, and logs any errors. Catch corruption early.
  • Avoid storing VHDX on ReFS volumes if you're on Server 2016 or earlier. ReFS has had metadata corruption bugs with VHDX. Stick to NTFS for now.

One last thing: always have a cold backup. The disk descriptor can be fixed, but the data behind it is precious. If you're reading this because a VM just died, you're about to learn why backups matter. Fix the descriptor, restore the data, and don't skip the backup next time.

Was this solution helpful?