Hyper-V Error Message Cheat-sheet

The aim of this article is to create a slowly growing cheat-sheet of Hyper-V Errors and known fixes.

Errors without Error Codes

These errors are UI errors that do not provide a Hex Error Code / Win32 Error Code.

There was an error during move operation.

Migration operation on ‘<VM Name>’ failed.


  1. 0x80041024
  2. 0x8000FFFF
There was an error during move operation.

Virtual machine migration operation failed at migration source.

Failed to create folder.

See 0x80070005


Errors with Error Codes

The following errors have error codes either stated on GUI error messages, as part of PowerShell error messages or in the Hyper-V event logs in Event Viewer.


Event ID: 21002 & 16300 & 1106

‘<Virtual Machine Name>’ Failed to create Planned Virtual Machine at migration destination: Unspecified error (0x80004005). (Virtual machine ID <Virtual Machine GUID>)

Cannot load a virtual machine configuration: Unspecified error (0x80004005). (Virtual machine ID <Virtual Machine GUID>)

vm\service\migration\vmmsvmmigrationdestinationtask.cpp(1781)\vmms.exe!00007FF650130A43: (caller: 00007FF65013359D) Exception(312) tid(19b4) 80004005 Unspecified error

vm\service\vmmgr\vmmsvirtualmachinemanager.cpp(4128)\vmms.exe!00007FF64FC867EB: (caller: 00007FF64FD83CC0) LogHr(97) tid(19b4) 80004005 Unspecified error
Msg:[vm\service\vmmgr\vmmsvirtualmachinemanager.cpp(5782)\vmms.exe!00007FF65025928F: (caller: 00007FF64FDA68AE) Exception(308) tid(19b4) 80004005 Unspecified error

Note: The Memory ranges, process ID’s and exception codes do not need to match the above, just the presence of 80004005.

  1. You cannot live migrate a VM back onto a hypervisor where it has been previously.
    This can occur if your Hypervisor loses storage (i.e. iSCSI). The Hyper-V VMMS process will obtain an opportunistic, persistently stuck request for a handle to a resource that was on the disk but can no longer be found. Restarting the hypervisor doesn’t clear the lock because it re-establishes when VMMS starts. Even if presented with the file resource, the lock will not establish.In the interest of safety, I strongly recommend exporting/Live migrating all VMs off of the hypervisor before attempting this fix. If you do not, you may lose the VMs and have to re-import them from their config files.Once the hypervisor has been drained of all VMs. Open services.msc and stop all Hyper-V processes. If they will not stop, reboot and then stop themBrowse to C:\ProgramData\Microsoft\Windows\Hyper-V.

    Delete data.vmcs

    Delete the contents of all xxxx Cache folders (e.g. Groups Cache, Planned Snapshots Cache… etc)

    Delete the contents of the Resource Types folder

    Reboot the server and retry the live migration

  2. Delete the VM configuration files for the VM in question and attach its existing VHDX(s) to a new set of configuration files. This will force the creation of a new VMID which will bypass the lock. This will not however solve the original issue (which may lead to other problems in the future) and for Windows VM’s may require Windows to be reactivated.

Event ID:

Virtual machine failed to generate VHD tree: ‘Catastrophic failure'(‘0x8000FFFF’).

  1. The configuration file references a VM checkpoint data-set that either has been lost from the file system or does not exist in the context of a VM that has been restored from backup. You will need to restore the checkpoint or edit the Virtual Machine Configuration file to resolve the error.For more information see ‘Hyper-V VM Stuck checkpoint after restore from backup

Event ID: 16000

The Hyper-V Virtual Machine Management service encountered an unexpected error: Provider is not capable of the attempted operation (0x80041024).

  1. One or both of the Hyper-V servers has an invalid or inaccessible IP address/network address on the “Incoming live migrations” list on the “Live Migrations” tab in Hyper-V settings.
  2. The live migration network is down, the/a cable is unplugged or faulty.
  3. On the destination Hypervisor issue the command:
    netstat -an | find "6600"
    If the query returns no results for TCP 6600 issue the command:
    net stop vmms & net start vmms
    Now re-test the netstat command.
    If the initial netstat command returns a result, or after it returns a result the migration still does not work, there is a firewall blocking traffic into TCP port 6600 on the destination hypervisor.
0x80070002 Could not create backup checkpoint for virtual machine ‘<VM Name>’: The system cannot find the file specified. (0x80070002). (Virtual machine ID <VM GUID>).

For more on this, seem my in-depth article.

  1. Check that you have enough disk space on the volume to perform the VSS. If your volume is sub-15%, try using the Hyper-V Manager to change the snapshot directory to another volume – plug in an external NTFS formatted hard drive if you have to.
  2. Check the permissions of the VHD stated in the error.
    icacls “C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks\<VHD File>” /grant “NT VIRTUAL MACHINE\Virtual Machines”:F
  3. Check that you can manually checkpoint/snapshot the VM while it is running.
    In Hyper-V Manager or in PowerShell, force a checkpoint on the VM and then delete it and wait for it to merge back. If this works, you are not having a physical VSS issue. If it fails, you need to troubleshoot this and not the WSB error.
  4. Live Migrate the VM off of the current server and onto a different Hypervisor, attempt the backup here, then bring it back to the original server and try again. This process will reset the permissions on the VM file set. If you cannot live or offline migrate the VM, the you need to troubleshoot this and not the WSB error.
  5. Ensure that all VHDX files associated with the VM are on the same storage volume and not spread across multiple Volumes/LUNs (be it individual disks, logical RAID or iSCSI disks). If they are, move them to a common location and retry the operation.

Event ID:

Hyper-V Replication could not be enabled

  1. Under Hyper-V Settings> Replication Configuration. Ensure that the path shown under ‘Specify the default location to store Replica files:’ is a valid path on the server
0x80070005 ‘General access denied error'(‘0x80070005’)

For more on this, see my in-depth article.

  1. If you are using a management console (not the local Hyper-V console to perform the migration. You must setup Kerberos Constrained Delegation for all of your Hyper-V hosts machine accounts in Active Directory.
  2. Ensure that both NetBIOS and fully qualified DNS entries exist in the Constrained delegation (click the “Expanded” check box to verify this) e.g. myserver1 and mysever1.mydomain.local for both “CIFS” and “Microsoft Virtual System Migration Service”.
  3. For Hyper-V 2008, 2008 R2, 2012 and 2012 R2 “Trust this computer for delegation to specified services only” should be used along with “Use Kerberos only”.
  4. For Hyper-V 2016 and 2019 or a mixed environment “Trust this computer for delegation to specified services only” must be used along with “Use any authentication protocol”.
0x80070057 vm\service\vmmgr\vmmsvirtualmachineobject.cpp(8731)\vmms.exe!00007FF64FDCB0D0: (caller: 00007FF65028C7DA) ReturnHr(110) tid(19b4) 80070057 The parameter is incorrect.
Msg:[vm\service\vmmgr\vmmsvirtualmachineobject.cpp(8725)\vmms.exe!00007FF64FE3C560: (caller: 00007FF65028C7DA) Exception(306) tid(19b4) 80070057 The parameter is incorrect.
]Note: The Memory ranges, process ID’s and exception codes do not need to match

  1. For more on this see 0x80004005, Event ID 21002 & 16300 & 1106

Event ID: 20306

The Virtual Machine Management Service failed to establish a connection for a Virtual Machine migration with host ‘<Hypervisor FQDN>’: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. (0x8007274C).

  1. The Live Migration firewall rules have not been enabled in Windows Firewall (or your third party firewall). This is especially easy to forget on Server Core and Hyper-V Server installs.
  2. No DNS server(s) or invalid DNS server(s) have been specified on the network configuration for the hypervisor.
  3. Specified DNS server(s) are unreachable.
  4. An intermediate firewall or IDS blocked the request. Ensure that you check that your migration NIC connections are not running in a ‘public/restricted LAN profile.

Event ID: 20306

The Virtual Machine Management Service failed to establish a connection for a Virtual Machine migration with host ‘<hostname>’: No connection could be made because the target machine actively refused it. (0x8007274D).

  1. If you are using a Windows NIC Team, there is a chance that the Hyper-V Management Service loaded before the NIC Team converged. This created a failed race condition. Consequently, the VMMS service will not have bound to Port 6600, causing this error. You can check for this condition by executing either of the following.
    netstat -an | find "6600"
    netstat -an | find `"6600`"If no results are returned for TCP Port 6600, you are impacted by this race condition.
    to solve the issue in the immediate term, execute either of the following.
    net stop vmms & net start vmms
    restart-service vmmsTo resolve the issue long-term. Use service.msc to set the ‘Hyper-V Management Service from ‘Automatic’ start to ‘Delayed Start’. This will usually be sufficient to ensure that the service binds correctly. If it is not, you will need to add a watchdog on the port binding and service.
  2. An intermediate firewall or IDS blocked the request. Ensure that you check that your migration NIC connections are not running in a ‘public/restricted LAN profile.

Event ID: 20302, 20306

Attempting to Live Migrate a VM between two servers from a third management workstation results in:

The Virtual Machine Management Service failed to authenticate the connection for a Virtual Machine migration at the source host: The logon attempt failed (0x8009030C).

The Virtual Machine Management Service failed to establish a connection for a Virtual Machine migration with host ‘<hostname>’: The logon attempt failed (0x8009030C).

Live Migration worked previously and Kerberos Constrained Delegation is verified as being correctly setup on the Domain Controller. Port 6600 is correctly servicing on both Hyper-V peers on the correct IP interface.

If you enable Kerberos Ticket Auditing on your domain controllers you receive Event ID 4769 with a failure code of 0x29:

A Kerberos service ticket was requested.

Account Information:
Account Name: <hostname>$@<domain name>
Account Domain: <domain name>
Logon GUID: {00000000-0000-0000-0000-000000000000}

Service Information:
Service Name: Microsoft Virtual System Migration Service/<fqdn>
Service ID: NULL SID

Network Information:
Client Address: ::ffff:
Client Port: 58871

Additional Information:
Ticket Options: 0x40830000
Ticket Encryption Type: 0xFFFFFFFF
Failure Code: 0x29
Transited Services: –

Error Code 0x29 or error KRB_AP_ERR_MODIFIED means that the Kerberos message checksum failed and the message is suspected of being modified in transit as a result of the checksum mismatch.

Possible ‘natural’ explanations for this include:

  1. The authentication data was encrypted with the wrong key for the intended server.
  2. The authentication data was modified in transit by a hardware or software error, or by an attacker.
  3. The client sent the authentication data to the wrong server because incorrect DNS data caused the client to send the request to the wrong server.
  4. The client sent the authentication data to the wrong server because DNS data was out-of-date on the client.

In this case it is likely that it is being caused by a bug in the Kerberos Service on Windows Server Domain Controllers as identified in an emergency out-of-bound patch release on 14th November 2021 for Windows Server 2008 R1 and higher.

View: Windows Message Centre Announcement

“Take action: Out-of-band update to address authentication issues on DCs relating to Kerberos delegation scenarios

Microsoft is releasing Out-of-band (OOB) updates today, November 14, 2021, to resolve issues in which authentication might fail on DCs with certain Kerberos delegation scenarios on all supported versions of Windows Server when used as a Domain Controller. To get the standalone update package, search for it in the Microsoft Update Catalog. You can import this update into Windows Server Update Services (WSUS) manually. See the Microsoft Update Catalog for instructions. Note These updates are not available from Windows Update and will not install automatically.”

You need to patch your Domain Controllers (not the Hypervisors) with the following KB’s and restart them to fix the problem: