Hyper-V VHDX Corrupt or Won't Mount? Don't Run Inspect-VHD.
UK Hyper-V data recovery specialists since 2002. Failed VHDX images, broken parent chains, corrupt CSV volumes, Storage Spaces Direct. Emergency UK collection. No-fix-no-fee.
Repair-VHD or Optimize-VHD on a suspect VHDX, do not let Hyper-V Manager merge a differencing chain, and do not delete checkpoints to free space. A corrupt VHDX may still hold a recoverable filesystem inside it; the wrong repair command can rewrite headers and make the contained NTFS or ReFS volume non-recoverable. A broken differencing chain (parent disk lost, AVHDX checkpoint orphaned) can be reassembled — but only if the AVHDX files are preserved exactly as they are. Power-off the affected VMs, leave all VHDX/AVHDX/CSV files in place, and call 0800 151 2207.What this means and what to do next
Hyper-V is Microsoft's hypervisor; VHDX is its virtual disk format, used by every Windows Server release from 2012 R2 to 2025. A VHDX file is a self-describing virtual block device — block allocation table, log, metadata, then the actual data extents. Inside that virtual block device is usually NTFS or ReFS, and on top of that is the workload: Active Directory, Exchange, SQL Server, file shares, line-of-business applications.
Hyper-V data loss takes three main shapes. First is corruption inside an otherwise intact VHDX — the host filesystem is fine, the VHDX file opens, but the NTFS/ReFS inside it is damaged (usually from a host-level power loss that interrupted writes mid-transaction). Second is corruption of the VHDX itself, often when the underlying storage had a hardware fault or a Cluster Shared Volume (CSV) experienced metadata loss. Third is a broken differencing chain — checkpoints (AVHDX files) that depend on a parent VHDX that has been deleted, moved, or renamed, leaving the differencing files unreadable without lab work.
The host storage layer matters enormously. A standalone Hyper-V host with local RAID is different from a clustered Hyper-V failover cluster on a SAN, which is different again from a Storage Spaces Direct (S2D) hyperconverged deployment. The recovery techniques are the same at the VHDX layer, but the imaging step underneath — getting at the VHDX files in the first place — is very different depending on the storage architecture.
The four most common Hyper-V VHDX recovery scenarios
1. Corrupt NTFS or ReFS inside an otherwise intact VHDX. Symptom: VHDX file mounts in Hyper-V Manager but the VM either fails to boot, boots to a recovery prompt, or boots and shows missing drives/folders. Cause: host-level power loss or controller failure interrupted writes to the VHDX, leaving the guest filesystem in an inconsistent state — Hyper-V's transaction log replays correctly but the NTFS/ReFS inside doesn't. Recovery: image the VHDX file out of the host (or out of an image of the host), then perform NTFS/ReFS recovery against the contents of the VHDX. The VHDX wrapper is ignored at this point; the filesystem inside is treated as if it were on a physical disk.
2. Corrupt VHDX file (header, BAT, or log damage). Symptom: Hyper-V Manager reports the VHDX file is corrupt, or refuses to mount it, or mounts it but reports the disk as size zero. Cause: the host filesystem had a corruption event in the bytes of the VHDX file itself — sometimes from RAID corruption, sometimes from a checkpoint operation that crashed partway through, sometimes from a defrag-style operation on the VHDX. Recovery: forensic recovery of the VHDX header structures, then reconstruction of the Block Allocation Table from the log and from secondary structures. This is specialist work — the VHDX format is documented but the recovery tooling is bespoke. Once the wrapper is repaired, the inner filesystem is recovered as in case 1.
3. Broken differencing chain — checkpoints orphaned from parent. Symptom: VM has checkpoints (AVHDX files), the parent VHDX has been deleted, moved, or renamed (sometimes accidentally during a storage migration), and the VM will not start because Hyper-V cannot resolve the chain. Cause: differencing disks are not self-contained — each AVHDX only contains changed blocks; everything else must come from its parent. If the parent is missing, the AVHDX is mostly unreadable. Recovery: locate any surviving snapshot/backup of the parent (even an older version of the parent can re-create most of the data when merged with the AVHDX changes), or reconstruct a synthetic parent from the AVHDX's content hints. We have proprietary tooling for this — many other labs do not.
4. CSV (Cluster Shared Volume) failure leaving VHDX inaccessible. Symptom: Hyper-V failover cluster reports the CSV as offline or in 'no direct access' mode, VMs on the affected CSV are paused, the VHDX files cannot be read from any cluster node. Cause: a fault in the underlying SAN or in CSV's coordinator role has left the cluster unable to mediate access. Recovery: bypass the cluster — image the underlying LUNs directly from the SAN, reconstruct the NTFS or ReFS that backs the CSV, then extract the VHDX files. This is essentially a layered recovery: storage layer first, host filesystem second, VHDX files third, guest filesystem fourth.
How Data Clinic recovers a Hyper-V environment
Step one is an architecture call. We will ask about the host topology: standalone Hyper-V or failover cluster, local storage or SAN or S2D, the Windows Server version, how many VMs are affected, what the host filesystem reports about the VHDX files, and what (if any) repair attempts have already been made. Hyper-V recovery decisions depend heavily on whether you have working host access — without it, we need to recover the underlying storage first.
Step two is imaging. For standalone hosts, we image the underlying volume (or the individual VHDX files) using PC-3000 imagers. For SANs and S2D deployments, we work with the customer's IT team or, for non-trivial cases, attend on-site to image the storage directly. Everything from here happens against images, not against the original storage, so the production environment is preserved.
Step three is the layered reconstruction described in the scenarios above. The output is recovered VHDX files (where the original VHDX wrappers were intact), recovered NTFS/ReFS contents (where the wrappers were not), or recovered Exchange databases / SQL databases / Active Directory NTDS.dit files where the customer's priority is application-level data rather than full VM restoration. We deliver in whatever form your environment can consume — VHDX, raw image, application database file — and provide a written report covering the architecture, the failure mode, the actions taken, and the integrity of the recovered data. More on our enterprise server recovery service →.
Get a free initial diagnosis in 60 seconds
In the tool below, choose RAID/NAS/Server and the symptom that matches — virtual disk corrupt, host server unbootable, CSV inaccessible, or differencing chain broken. The tool routes Hyper-V cases to our virtualisation recovery team.
What our customers say
"Three years of family photos on a drive that suddenly failed. Data Clinic collected next day, kept me updated through the cleanroom work, and got everything back. Worth every penny."
"Honest, fixed-price, no-fix-no-fee. Quoted by another lab at three times the price. Recovered 100% of my files."
"Reasonable cost, clear communication, and they were straight with me about what was recoverable and what wasn't. Recommended."
Frequently asked questions
Can you recover from a Hyper-V failover cluster with a failed CSV?
Yes. We work at the storage layer — imaging the underlying LUNs from the SAN, reconstructing the host filesystem (NTFS for legacy CSV, ReFS for current deployments), and then recovering the VHDX files from that. We can do this without a working failover cluster; the cluster software is only relevant when the storage is healthy. Once the storage is imaged, the cluster is no longer in the recovery path.
My differencing chain has lost its parent VHDX — is the data recoverable?
In most cases yes, with caveats. The AVHDX files contain only the blocks that changed since the parent — typically a few hundred MB to a few GB of changes. If the parent is found anywhere (older backup, replication target, even a damaged disk where the file once lived), we can merge the AVHDX onto it. If the parent is completely lost, we can sometimes reconstruct enough of it from the AVHDX's content hints to recover most data. This requires specialist tooling; we will tell you within 48 hours whether your case is recoverable after a free assessment.
Will Inspect-VHD or Repair-VHD fix a corrupt VHDX?
Sometimes — and sometimes not. Inspect-VHD is read-only and safe; it will tell you what the VHDX header looks like. Repair-VHD attempts to repair the VHDX structure. On a lightly damaged VHDX it can work cleanly. On a heavily damaged VHDX it can rewrite headers in ways that make subsequent recovery harder. As a rule, if Inspect-VHD reports anything other than 'no errors', stop and let us assess before running Repair-VHD.
Can you recover Exchange databases, SQL databases, or Active Directory from inside a damaged VHDX?
Yes. The application databases — EDB files for Exchange, MDF/LDF for SQL Server, NTDS.dit for AD — are recovered as files from the inner NTFS/ReFS once the VHDX is imaged. Where those application files themselves are damaged, we apply application-aware recovery tools — eseutil for Exchange and AD, DBCC and DBCC CHECKDB for SQL Server, and specialist forensic tools where the standard utilities fail. Many enterprise recoveries are scoped to a single application (e.g. 'recover the Exchange databases'); we can quote that way.
How long does Hyper-V recovery take?
Standalone host with intact VHDX files: 3–5 working days. Corrupt VHDX with intact host filesystem: 4–7 days. Broken differencing chain: 5–10 days depending on whether the parent can be located. CSV failure with SAN imaging: 1–3 weeks depending on the SAN size. Emergency 24/48 hour services are available for business-critical cases — we routinely deliver Exchange-only recoveries inside 48 hours when the rest of the environment can wait.
Do you handle Storage Spaces Direct (S2D) hyperconverged deployments?
Yes. S2D recoveries are technically demanding because the data is striped across multiple nodes with software-defined mirroring/parity, but the principles are the same: image each node's local storage, reconstruct the virtual disks at the S2D layer, then extract the VHDX files. We have done S2D recoveries on Windows Server 2016, 2019, 2022, and 2025.