Hyper-V VM Access Denied Fix (0x80070005)

When this error appears

You've got a Hyper-V VM that's been running fine for months. Then one day you try to start it—maybe after a Windows update, or after moving the VM's storage to a new drive—and you get an error: ''Virtual machine could not be started because the hypervisor is not running'' or just ''Access Denied'' with code 0x80070005. Or maybe you see a red exclamation mark in Hyper-V Manager and the VM shows 'Stopped' but won't power on.

I've seen this happen most often after someone moves VHD files to a new folder, or after a Windows Server security update tightens permissions. The VM itself might still be registered in Hyper-V Manager, but the hypervisor can't access its virtual hard disks or snapshot files.

Root cause

Hyper-V's worker processes (VMMS.exe and VMWP.exe) run under the NT VIRTUAL MACHINE\Virtual Machines group, not your user account. That group needs Read/Write permissions on every file the VM uses—VHDX/VHD files, AVHDX snapshot files, and even the VM's configuration XML file. If any of those files lost their inherited permissions (common when you move them through Windows Explorer), the VM won't start.

Another less common cause: the Hyper-V service account itself has been changed or corrupted. I've also seen this from antivirus software that locks VHD files.

The fix: Restore permissions on VM files

First, identify which VM is broken. Open Hyper-V Manager, click the VM that won't start. Look at the bottom pane for the error text. Write down the VM name.
Close Hyper-V Manager. Don't try to start the VM again yet—it'll just waste time.
Open File Explorer and find the VM's files. By default, they're in C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Hard Disks for VHDs and C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines for config. But if you moved them somewhere else, go there.
Right-click the VHDX file (or VHD) that belongs to this VM. Choose Properties, then the Security tab.
Check if 'Virtual Machines' appears in the list. Look for a group called NT VIRTUAL MACHINE\Virtual Machines. If it's missing, that's your problem.
To add the group:
- Click Edit (or Advanced, then Add).
- Type NT VIRTUAL MACHINE\Virtual Machines into the object name field.
- Click Check Names. It should resolve to something like Virtual Machines.
- Click OK.
Set permissions for that group:
- Give it Modify and Read & Execute. (Modify includes Write, which Hyper-V needs for snapshots.)
- Click OK to close the permission window.
Do the same for every snapshot file (AVHDX or AVHD) that belongs to this VM. If you don't know which files go with it, look in the VM's settings in Hyper-V Manager—right-click the VM, choose Settings, then click each hard drive listed. The path appears there.
Also check the VM's configuration file (a .xml file in the Virtual Machines folder). It needs the same permissions.
Now try starting the VM again. Open Hyper-V Manager, right-click the VM, choose Start. If it works, you're done. If it doesn't, move on to the next step.

If it still fails

Sometimes the permissions fix isn't enough. Here's what else to check:

Thing to check	What to do
Hyper-V service account	Open Services.msc, find Hyper-V Virtual Machine Management. Right-click, Properties. Make sure it runs as Local System (or Network Service if you changed it for some reason). Click Recovery tab, set first failure to Restart the Service. Then restart the service.
Antivirus interfering	Add the VM's storage folder to your antivirus exclusion list. I've seen McAfee and Symantec lock VHD files. Do this even if you just think it's fine.
Storage change	If you moved the VHD to a new drive, check that drive's permissions. The Everyone group needs at least Read access to the root of that drive, though I prefer giving Authenticated Users Read. The VM group needs full control on the VHD folder itself.
File ownership	Right-click the VHD file, Properties, Security tab, Advanced. Look at the Owner. If it says something weird like an old user SID, click Change and set it to Administrators or SYSTEM. Apply, then recheck permissions.
Check Event Viewer	Open Event Viewer, go to Applications and Services Logs > Microsoft > Windows > Hyper-V-VMMS > Admin. Look for error events at the time you tried to start the VM. The details often mention exactly which file has a permissions problem.

One more trick: if the VM was created on a different machine, the SID of the Virtual Machines group might not match. In that case, export the VM, delete it from Hyper-V Manager, then re-import it. The import process re-creates the correct permissions automatically.

That's the whole fix. Nine times out of ten, it's just missing permissions on the VHD file. You'll get your VM back in five minutes.