VMware Workstation Unrecoverable Error (vcpu-0): Exception 0xc0000005 Fix

If VMware Workstation refuses to power on a VM with this message, you're in the right place:

VMware Workstation unrecoverable error: (vcpu-0)
Exception 0xc0000005 (access violation) has occurred.

The vCPU number changes (vcpu-0, vcpu-1…) but the cause is the same. It shows up most often on Windows 11 hosts, typically after a Windows feature update or after moving a VM to a new PC. The fixes below are ordered from safest to most invasive. Try them in order, and test the VM after each one.

VMware Workstation unrecoverable error Exception 0xc0000005

Applies to: VMware Workstation Pro / Player 15, 16, 17 and later on Windows 10 and Windows 11 hosts.

Quick answer

Update VMware Workstation to the latest release. This fixes most cases on Windows 11.
If the VM was suspended, discard the suspended state.
Turn off 3D graphics acceleration for the VM.
Only if those fail, turn off Memory integrity / VBS / Hyper-V on the host. That reduces host security, so treat it as a last resort.

Why it happens

Since Workstation 15.5.5, VMware can run on top of Microsoft's hypervisor (Hyper-V, Virtualization-Based Security, WSL 2, Windows Sandbox) through the Windows Hypervisor Platform. Older Workstation builds, and some host CPU or driver combinations, crash the virtual CPU when they hit those Windows security features. You see that crash as an "access violation". Suspended VMs moved between hosts or Workstation versions can trigger the same crash when they resume.

Fix 1: Update VMware Workstation

Workstation 16 and earlier have known problems with Windows 11's virtualization stack. Upgrading to the current 17.x release (or newer) is the fix that works most often. A reader in the comments confirmed that moving to 17.5 fixed it after the other fixes didn't.

VMware Workstation Pro is now free for personal and commercial use and is downloaded from the Broadcom support portal. Install it over the top of your current version; your VMs aren't touched.

Fix 2: Discard the suspended state

If the VM was suspended (not shut down) before you upgraded Workstation, changed hosts or changed CPU, resuming it can crash immediately.

Select the VM in Workstation.
Use VM → Power → Discard Suspended State (if offered).
Or close Workstation and move the VM's .vmss and .vmem files out of the VM folder.

You lose whatever was in memory when it was suspended, but the virtual disk is untouched.

Fix 3: Disable 3D graphics acceleration

GPU driver problems on the host are another common trigger.

Power off the VM.
VM → Settings → Hardware → Display.
Uncheck Accelerate 3D graphics and click OK.

You can do the same in the VM's .vmx file with mks.enable3d = "FALSE". Also update the host GPU driver from the manufacturer's site, not only through Windows Update.

Fix 4: Turn off Memory integrity (Core isolation)

Windows Security → Device security → Core isolation details.
Turn Memory integrity off and restart.

Fix 5: Turn off VBS and the Windows hypervisor

This is the workaround VMware published for this error (KB 2146361). Use it only when nothing else works, because it disables security features many organisations require, and it also breaks WSL 2, Docker Desktop and Windows Sandbox.

Disable Virtualization-Based Security via Group Policy:

Run gpedit.msc.
Go to Computer Configuration → Administrative Templates → System → Device Guard.
Set Turn On Virtualization Based Security to Disabled.

Turn off the Hyper-V platform features: Turn Windows features on or off → untick Hyper-V, Virtual Machine Platform and Windows Hypervisor Platform.

Stop the hypervisor from starting at boot (elevated Command Prompt):

bcdedit /set hypervisorlaunchtype off

Restart the host. To check that it took effect, run systeminfo. The last section should list the Hyper-V requirements instead of "A hypervisor has been detected".

To undo all this later:

bcdedit /set hypervisorlaunchtype auto

Still crashing? Read vmware.log

Each VM folder contains a vmware.log. Search it for 0xc0000005 or Unrecoverable and look at the lines just before. They usually name the module that crashed, such as a graphics driver DLL, an antivirus hook or a specific device. Then:

Antivirus or endpoint protection: temporarily exclude the VMware program folder and the VM folder.
Removed devices: a VM pointing at a USB device, ISO or serial port that no longer exists. Remove the device from VM settings.
Corrupted VM config: create a new VM and attach the existing .vmdk as its disk.
Clean reinstall: uninstall Workstation, restart, delete C:\ProgramData\VMware and reinstall.

Common scenario: moving VMs to a Windows 11 PC

This often shows up when a Windows 10 guest is copied from an older host (Workstation 15/16 on Windows 8.1 or 10) to a new Windows 11 machine while still suspended. Shut VMs down completely before moving them, then upgrade Workstation on the new host.

FAQ

Is it safe to disable Memory integrity and VBS?

It works, but it removes protection against kernel-level malware and credential theft. On a work device, check with your security team first. Updating Workstation is the better fix.

Why did this start after a Windows update?

Feature updates often switch on Memory integrity or Virtual Machine Platform by default, which exposes the incompatibility in older Workstation builds.

Does this affect VMware Player too?

Yes. Workstation Player uses the same engine, and the same fixes apply.