VHD Will Not Attach Calm Checks for Corrupt Files and Disks Locked by a VM
Attach failed, error message vague, panic rising. Stop. Most 'corrupt VHD' cases are nothing of the sort - the disk is locked by a VM, already mounted, or blocked by a file attribute. The genuinely corrupt ones announce themselves differently. Here is the order that separates them.
✍️ Technical Anshu🪟 Windows 10 / 11⏱️ 8 minute read
🎥 Watch the video for normal attach and detach behaviour - you need to know what healthy looks like before diagnosing sick
A VHD that refuses to attach produces some of Windows' least helpful error messages - 'the process cannot access the file', 'a virtual disk support provider for the specified file was not found', or a flat failure with no reason at all. Behind those messages sit five very different problems with five very different fixes. This guide works them in the right order: locked, already mounted, attributes, location, and only then corruption. And it explains the one relationship behind half of all cases: the same file cannot do two jobs at once.
Ask in this order before saying the word corrupt
1. Is a VM using this disk right nowMost common
2. Is the disk already mounted on this PCVery common
3. Read-only attribute, permissions, long pathCommon
4. File on USB, network share or inside another VHDSometimes
5. The file itself is genuinely damagedRare - last
👆 Work top to bottom. Four times out of five the answer is in the first three lines, and the file was never damaged at all.
1
Cause One - A Virtual Machine Owns the Disk
A running virtual machine holds its disks exclusively. The host cannot mount a disk that a VM is using - the refusal is Windows protecting the file system from two writers
This includes VMs that look 'off-ish': saved state and paused VMs still hold their disks. Shut the VM fully down, then attach
The same file, two jobs: a VHDX is either a VM's disk or a drive mounted in the host - one job at a time, never both together. Two writers on one file system image is precisely how corruption is manufactured
Need the data while the VM runs? Use the VM's own networking or shared folders, or shut down, copy the file, and mount the copy. The copy trick is safe because the copy takes its own job
Watch for checkpoints: a VM with checkpoints writes to an AVHDX child, and the base VHDX is locked into that chain - mount the base and you are reading a past state and risking the chain
2
Cause Two - It Is Already Mounted, or the Path Is Lying
Open Disk Management first. If the disk is already attached - possibly with no drive letter, which is why Explorer shows nothing - attaching again fails. Assign a letter, or detach and re-attach cleanly
Check the file path you are feeding the tool: moved folders, renamed files, and shortcuts pointing at yesterday's location produce 'provider not found' style errors that read like corruption but are just a missing file
Very long paths and files buried under odd characters can trip older tooling. Copy the file to a short, plain path like D:\VHD\Disk.vhdx and try again - this test also rules out a failing source location
Permissions: a file created under another user or copied from a protected folder may deny your account. Check the file's Security tab; take ownership only if you understand why the ACL is what it is
3
Cause Three - The Read-Only Attribute and Other File Flags
If the .vhdx file carries the Windows read-only attribute (common after copying from a DVD or a backup set that marks files), attaching it for writing can fail or silently attach it in a limited way
Right-click the file → Properties → untick Read-only, then attach again
Actually want it read-only? Then say so properly: Mount-VHD -Path "D:\VHD\Disk.vhdx" -ReadOnly, or in DiskPart, attach vdisk readonly. A deliberate read-only attach works; an accidental one just confuses
Files marked as sparse, compressed by NTFS compression at the host level, or stored inside a sync folder that has 'files on demand' placeholders can all misbehave - for a disk you are about to mount or give to a VM, keep the file fully downloaded, uncompressed, and local
4
Cause Four - Where the File Is Sitting
USB sticks and slow external drives: mounting a data VHD from one works but crawls, and a loose cable mid-write is a corruption factory. Fine for a look, wrong for daily use
Network shares: Disk Management may refuse, and Hyper-V has strict requirements for hosting VM disks on shares. For anything beyond a quick peek, copy the file local first
Inside another mounted VHD: nested paths make tools and humans equally dizzy, and native boot forbids it outright. Keep virtual disks on real volumes
The host disk is full: a dynamically expanding disk that cannot grow will error at attach or first write. Check host free space before suspecting the file
5
Cause Five - Genuine Corruption, and the Honest Recovery Ladder
Real corruption has a story: power cut mid-write, host disk developing bad sectors, someone force-killing a VM daily for a month. A VHD (no protective log) from that life is a prime suspect; VHDX survives most of it by design
Read the disk's state without opening it: Get-VHD -Path "D:\VHD\Disk.vhdx" reports format, size and health information, and Hyper-V's Inspect Disk examines the chain. If even inspection fails, the damage is structural
Do not let repair tools loose on your only copy. Copy the file first - even a damaged copy can be worked on; your original stays the untouched fallback
chkdsk has a precise, limited role: it checks the host volume the file sits on, or the volume inside the VHD after a successful attach. It cannot repair a broken VHD header or chain. Anyone promising that is selling something
The final rung is the honest one: restore from the backup copy of the file. A virtual disk you cannot afford to lose deserves the same backup discipline as the machine it serves - prevention here is not a slogan, it is the entire cure
🔴 Never force-mount a disk that a VM might still own. If a tool or trick offers to break the lock and attach anyway, understand what you are accepting: two systems writing to one file system, and corruption that may not show for days. Shut the VM down, or mount a copy. There is no third safe option.
🎥 Watch the Complete Process in the Video
Watch the video to see healthy attach and detach behaviour - with that picture in mind, every failure in this guide becomes easy to place.
Attach says the file is in use, but no virtual machine is running. What else holds it?
Work the usual suspects: the disk may already be mounted on this same PC (check Disk Management - it may have no drive letter, so Explorer gives no hint). A VM in saved or paused state still owns its disks. Backup software, an antivirus scan, or another management tool can hold the file briefly. And if it is a checkpoint chain member, Hyper-V holds the family together. Detach it properly or shut the owner fully down, then attach.
Can chkdsk repair my corrupt VHD file?
Not the file itself. Chkdsk repairs file systems: the host volume that stores the VHD, or the volume inside the VHD once it attaches. A damaged VHD header, metadata or differencing chain is structural damage chkdsk was never built to touch. Your real tools are Get-VHD and Inspect Disk for diagnosis, working on a copy for any recovery attempt, and the backup of the file for the actual rescue.
The VHD mounts but shows as RAW or unallocated. Is the data gone?
Not necessarily. RAW usually means the partition table or the file system's opening structures are unreadable, while the data deeper inside often survives. Stop writing to it immediately - do not let Windows 'helpfully' initialize or format it, since that prompt is offering to erase your chances. Copy the file, then work on the copy with partition recovery tools, or restore from backup. Initializing feels harmless and is the single most destructive click in this situation.
This guide is based on the Technical Anshu Windows VHD video • Stuck on any step? Ask in the video comments — you will get a reply there 🙏