How to Fix “Hyper-V Virtual Machine Stuck on Starting 10%” Error on Windows 11

Had a VM hang at “Starting (10%)” for twenty straight minutes on my Windows 11 dev box last month, right after a routine update. No error, no crash, just a progress bar that had apparently given up on life. If you’re staring at the same thing right now, the good news is this is one of the more diagnosable Hyper-V problems — the bad news is there are about six different root causes that all produce the exact same symptom.

Quick Answer

• Kill the stuck vmwp.exe process for that specific VM through Task Manager, then try starting it again
• Check that Hyper-V Virtual Machine Management and Hyper-V Host Compute services are running
• If it only happens with a network adapter attached, temporarily detach it and test again
• Check your antivirus isn’t blocking vmwp.exe — this is a genuinely common and overlooked cause
• Corrupted .vmrs or .vmgs state files can also cause this and usually need to be deleted so Hyper-V rebuilds them

Why This Happens

The 10% mark specifically corresponds to a fairly early stage in the VM boot sequence, where Hyper-V’s Virtual Machine Worker Process (vmwp.exe) is initializing the VM’s virtual hardware and handing off to the Virtual Machine Management Service. When it hangs right there, it usually means one of a handful of things is blocking that handoff:

1. Antivirus or filter driver interference. Third-party antivirus, and sometimes Windows Defender itself under aggressive settings, blocks vmwp.exe from doing what it needs to do during initialization. From what I’ve seen, this is way more common than people expect, especially after AV definition updates roll out silently in the background.
2. A stuck or corrupted worker process from a previous session. If a VM wasn’t shut down cleanly, its old vmwp.exe instance can still be holding a lock on files the new startup attempt needs, which stalls the new one indefinitely.
3. Network adapter conflicts. Multiple documented cases show VMs hanging at 10% specifically when a network adapter is attached, and starting fine with it detached — <cite index=”21-1″>this has been reported specifically on Windows 10 and 11 devices where the VM hangs at 10% on startup when a network adapter is attached, but starts successfully once the adapter is disconnected</cite>.
4. Corrupted VM state files. The .vmrs (runtime state) and .vmgs (guest state) files can get damaged after an unclean shutdown or a failed save operation, and Hyper-V can’t cleanly resume past that point.
5. Permissions issues on VM storage. If the Hyper-V service account or the SYSTEM account doesn’t have full control over the VM’s folder and VHDX files, initialization stalls without a clean error message.
6. A misbehaving Authenticated Users group membership. This one’s older and less common on fresh Windows 11 installs, but it still surfaces occasionally — <cite index=”19-1″>one confirmed root cause in a similar case was “Authenticated Users” being present in the local administrators group, and removing it from that group resolved the issue</cite>.

Common Scenarios

Step-by-Step Fixes

Step 1: Kill the Stuck Worker Process

Every running VM has its own vmwp.exe instance. If a previous session left one stuck, it’ll block the new start attempt.

1. Open Task Manager → Details tab
2. Look for vmwp.exe — if you’ve only got one VM, there’s no ambiguity. With multiple VMs, you’ll need the VM’s GUID to identify the right instance
3. To find the GUID: open the VM’s storage folder in File Explorer and look at the .vmcx configuration file name, or run this in PowerShell:

Get-VM -Name "YourVMName" | Select VMId

4. Match that GUID against the vmwp.exe process (PowerShell’s Get-Process with a bit of filtering works better than eyeballing Task Manager if you’ve got several running)
5. End the matching process, then try starting the VM again through Hyper-V Manager

Step 2: Restart Hyper-V Services

Restart-Service vmms

This restarts the Virtual Machine Management Service. If that alone doesn’t fix it, also check that Hyper-V Host Compute Service is running via services.msc — both need to show Running with Automatic startup type.

Step 3: Test With the Network Adapter Detached

If the VM only hangs with a network adapter connected, this points at a virtual switch problem rather than the VM itself.

1. Shut the VM down completely (force it off if needed via Step 1)
2. In VM Settings, remove or disable the network adapter
3. Try starting the VM again
4. If it starts cleanly this time, the issue is in your virtual switch configuration — recreating the switch in Virtual Switch Manager usually resolves it

Step 4: Check Antivirus Exclusions

Add vmwp.exe and your Hyper-V VM storage folder to your antivirus exclusion list. On Windows Security, this goes under Virus & threat protection settings → Exclusions. If you’re running third-party AV, check their documentation for the equivalent — Microsoft maintains an official list of recommended Hyper-V exclusions worth cross-checking against whatever you’re running.

Step 5: Delete Corrupted State Files

If the VM was previously saved or checkpointed and the state looks damaged:

1. Make sure the VM is fully powered off (not paused or saved)
2. Navigate to the VM’s storage folder — usually under the Virtual Machines directory, not the Snapshots folder
3. Delete .vmrs and .vmgs files if present
4. Start the VM again — Hyper-V will rebuild these files, though the VM will start from a powered-off state rather than resuming any previous saved state

Step 6: Check File and Folder Permissions

The SYSTEM account and the Hyper-V Virtual Machine Management Service need full control over the VM’s folder and its VHDX files. Right-click the folder → Properties → Security, and confirm SYSTEM has Full Control. If it doesn’t, add it.

What Actually Worked For Me

My case turned out to be embarrassingly simple, which almost never happens with Hyper-V weirdness. I went through the usual checklist first — killed the worker process, restarted the VMMS service, checked permissions, all clean. Nothing.

So I detached the network adapter as a test, mostly expecting it wouldn’t matter. And it started immediately. Turned out I’d installed a VPN client a few days earlier that added its own virtual network adapter, which apparently confused the Default Switch enough to stall VM initialization whenever a VM tried to bind to it. Not something any of the official troubleshooting docs mention specifically, but it tracked with a pattern I’d seen in a few forum threads about network adapter conflicts.

Recreating the virtual switch from scratch in Virtual Switch Manager fixed it permanently — I didn’t even need to uninstall the VPN client, just rebuild the switch after it was installed. Your mileage may vary here depending on what’s actually creating the adapter conflict, but if you’ve recently installed anything that touches networking (VPN software, another hypervisor, a Docker Desktop update that reconfigures WSL networking), that’s worth testing before you go deep into permissions and state file troubleshooting.

Advanced Fixes and Edge Cases

Checking Event Viewer for the specific timeout. Under Applications and Services Logs → Microsoft → Windows → Hyper-V-Worker Admin, look for Event ID 3062, which specifically indicates the Virtual Machine Worker Process initialization timed out. This confirms you’re dealing with this exact issue rather than a different startup failure with similar symptoms.

BitLocker interference. If the host drive holding your VM files is BitLocker-encrypted and got locked after an update or restart, Hyper-V can’t access the files it needs and the VM stalls. Check BitLocker status on that drive and unlock it if needed before retrying.

Checking for competing hypervisors. If VMware, VirtualBox, or WSL2 with its own virtualization stack is also active, they can conflict over the hardware virtualization extensions. Run:

bcdedit /set hypervisorlaunchtype auto

and reboot if you suspect this.

Corrupted configuration after a failed migration or abrupt shutdown. If the .avhdx differencing disk got orphaned from its parent, Hyper-V won’t recognize the VM properly. Microsoft’s own troubleshooting guidance for this scenario points to running <cite index=”24-4″>Set-VHD with the Path, ParentPath, and IgnoreIDMismatch parameters to reattach an orphaned differencing disk to its parent</cite>.

Export and reimport as a last resort. If nothing above works, exporting the VM (with it powered off) and reimporting it as a fresh registration often clears whatever corrupted internal state was causing the hang, without touching your actual VHDX data.

What Rarely Works

Just rebooting the host machine is the fix everyone tries first, and it does work sometimes — but only because it clears a genuinely transient lock, not because it addresses any underlying cause. If the hang comes back after a day or two of normal use, rebooting was never the fix, it was just a reset button. Same goes for reinstalling the Hyper-V feature entirely; it’s disruptive and in most of the cases I’ve seen documented, it doesn’t touch the actual root cause (permissions, AV, or network adapter conflicts).

Prevention Tips

• Keep antivirus exclusions for Hyper-V configured before you hit this problem, not after
• Shut VMs down cleanly rather than force-closing the host or losing power mid-session
• Avoid installing additional virtualization or VPN software without testing existing VMs afterward
• Periodically export critical VMs as a backup so a corrupted state file doesn’t cost you actual work
• Keep Windows and Hyper-V components patched, since several historical instances of this bug were tied to specific cumulative updates that got fixed in later patches

FAQ

Does this happen on Windows 11 Pro and Enterprise both? Yes, it’s not edition-specific. The underlying vmwp.exe and VMMS mechanics are the same across Pro, Enterprise, and Windows Server.

Will I lose data if I kill the worker process? If the VM hasn’t actually started (still stuck at 10%), there’s no running guest OS state to lose. It’s a safe action in this specific scenario.

Why does this only happen sometimes, not every time I start the VM? Usually points to a resource contention or timing issue — antivirus scanning at the wrong moment, or a network adapter that’s intermittently available. Consistent hangs point more toward permissions or corrupted state files.

Is this related to Windows Sandbox or WSL2 having similar startup issues? Not directly, though they share some of the same underlying hypervisor platform. Fixes for one don’t reliably apply to the other.

Editor’s Opinion

honestly the network adapter thing catches people off guard more than it should given how documented it is. if your vm only hangs with networking attached, test that first before you go killing processes and messing with permissions, could save you twenty minutes. and if none of this works, just export and reimport, it fixes more of these than it gets credit for