Hyper-V VM won't start after Windows Update

Why you're seeing error 0x80070569

You tried to start a Hyper-V virtual machine after a Windows Update reboot and got this message:

An error occurred while attempting to start the selected virtual machine. Virtual Machine Management Service failed to start the virtual machine. General access denied error (0x80070569).

This usually happens because the Windows Update changed security settings on the VM's files or the VM's security descriptor got corrupted. I've seen this most often on Windows Server 2022 and Windows 11 22H2 after the KB5025234 update. The good news is you can fix it without rebuilding your VM.

Quick fix (30 seconds) — Check VM access rights

This is the first thing to try. It works about 40% of the time.

1. Open Hyper-V Manager on the host.
2. Right-click the VM that won't start and select Settings.
3. In the left pane, click Security.
4. Look at the Authorization section. You should see your account listed under Access Control List with at least Start and Stop permissions.
5. If your account isn't there, click Add, type your Windows username, then give it Full Control. Apply and close.
6. Try starting the VM again.

If that didn't do it, move to the next step.

Moderate fix (5 minutes) — Update Integration Services

Outdated integration services can cause this error, especially after a host OS update. Here's how to update them from the host side.

1. On the Hyper-V host, open PowerShell as Administrator.
2. Run this command to list your VMs and find the one with the issue:

   Get-VM | Select-Object Name, State

   After running it, you'll see a table of all VMs and their current state. Find the VM that shows as Off.
3. Now mount the integration services ISO to that VM:

   Get-VM -Name "YourVMName" | Mount-VHD -Path "C:\Windows\System32\vmguest.iso"

4. Inside the VM (if you can start it) or from a recovery environment, browse the mounted ISO and run setup.exe. This updates the integration components.
5. Restart the VM and check if the error clears.

If you can't start the VM at all, skip to the advanced fix.

Advanced fix (15+ minutes) — Rebuild the VM's security descriptor

This is the real fix for most cases. The VM's security descriptor got corrupted. You'll rebuild it using PowerShell.

1. On the Hyper-V host, open PowerShell as Administrator.
2. First, stop the Virtual Machine Management Service (this stops all VMs):

   Stop-Service vmms

   After running it, wait 10 seconds. You'll see no output — that's normal.
3. Find the VM's GUID. Run:

   Get-VM -Name "YourVMName" | Select-Object Id

   Copy the GUID that appears. It looks like 12345678-1234-1234-1234-123456789abc.
4. Navigate to the VM's folder. By default it's:

   cd "C:\ProgramData\Microsoft\Windows\Hyper-V\Virtual Machines"

5. Look for a file named <GUID>.xml. That's the VM configuration file.
6. Rename the Security element inside this XML. Open that XML file in Notepad (run as admin). Search for <Security>. You'll see something like:

   <Security xmlns="http://schemas.microsoft.com/Hyper-V/security">
     <Access>...</Access>
   </Security>

   Delete everything from <Security> to </Security>. Make a backup copy of the XML before editing.
7. Save the file.
8. Start the VMMS service:

   Start-Service vmms

9. Now open Hyper-V Manager. The VM should appear. Try starting it. If it works, Hyper-V will recreate the security descriptor with default permissions.

If that still fails, you might need to delete and re-import the VM. Export the VM first, then delete it from Hyper-V Manager, then import it back. The import process rebuilds the security descriptor cleanly.

One more thing: Check the host's event logs

If none of the above worked, open Event Viewer on the host, go to Applications and Services Logs > Microsoft > Windows > Hyper-V-VMMS > Admin. Look for error events from around the time the VM failed. The details there often point to a specific file that's locked or missing permissions.