Recover VMDK or VHDX deserves a clear, practical explanation. When a virtual machine will not boot, the instinct is to fight the hypervisor. Usually that is the wrong end of the problem. The VM configuration is disposable; the virtual disk file holds everything you care about. Get the data out of the file and you can rebuild the rest in an afternoon.
The short answer. Try mounting the disk read-only on the host first — Disk Management for VHDX, VMware’s mount utility or 7-Zip for VMDK. If that fails, the container is damaged and you need a tool that can read a virtual disk image directly rather than asking the OS to attach it.
Recover VMDK or VHDX: Mount it read-only before anything else
For VHDX on Windows: Disk Management, Action, Attach VHD, and tick Read-only. That tick box matters. Attaching read-write lets Windows “helpfully” replay a dirty log or run a repair, and a repair on a damaged container can make things worse.
For VMDK: VMware’s own vmware-mount does the job on a healthy file. If the disk is split into many 2 GB extents, you need every extent present and the descriptor file intact — a missing extent will fail the mount even though most of your data is sitting right there.
Snapshot chains are where most of these go wrong
If the VM ever had a snapshot, the base disk is not the current state. The current state is the base plus every delta in the chain, applied in order. Delete one delta, or lose the descriptor that names them, and the chain breaks — which is exactly what happens when someone tidies up a datastore that is running out of space.
Before you do anything else, list every file in the VM folder and look for the chain: a base disk plus files with sequential numbers, or a chain of AVHDX files on Hyper-V. If a middle link is missing, the honest position is that data written after that point is gone. What came before it is usually still recoverable from the base.
24H2 writes more in the background
The practical consequence is that you have hours, not days. MiniTool Power Data Recovery scans a single folder or volume quickly and previews results, so you can get an answer before the next update service write lands on top of your file.
Scan quickly with MiniToolAffiliate link — we may earn a commission at no extra cost to you.
When the container itself is damaged
A VMDK or VHDX truncated by a full datastore, an interrupted copy or a failing host drive will not attach at all. At that point the useful move is to stop treating it as a disk and start treating it as a file full of filesystem structures. Recovery software that understands virtual disk formats can walk the image, find the partition table and the NTFS or ext4 structures inside it, and pull files out without ever needing the container header to be valid.
- Always work on a copy. Copy the VMDK or VHDX to another physical drive first and recover from the copy.
- Never run a repair tool against the only copy you have.
- If the host drive is what failed, image the host drive before touching the virtual disk on it.
- Recover to a location outside the datastore. Filling the datastore again is how the first failure happened.
Reading a virtual disk that will not mount
Stellar Data Recovery reads VMDK, VHD and VHDX images directly and reconstructs the filesystem inside them, which is the step a failed mount is blocking. It handles the case where the container header is damaged but the data area is intact — by far the most common way these files break.
Rebuild the VM, not the file
Once the data is out, do not try to resurrect the original machine. Create a fresh VM, attach a new disk, restore the data onto it. A virtual disk that has already failed once, been mounted, repaired and scraped is not something you want carrying your production workload.