VM checkpoint restore fails with error 0x800423F4

You're running Hyper-V on Windows Server 2016 or 2019. You try to apply a checkpoint to a VM that's been running for a few days. The restore starts, and then it stops. You get error 0x800423F4 in the Hyper-V manager or in the event log. The VM might go into a paused state. Sometimes you see a message about the Volume Shadow Copy Service (VSS) failing. This usually happens when the VM has a lot of disk writes happening, or when the checkpoint file (.avhdx) is big and the merge process runs out of time or disk space.

The root cause is almost always one of two things. First, the VSS writer inside the VM (if it's a production checkpoint) is stuck or hung. Second, the host drive where the checkpoint files sit doesn't have enough free space to complete the merge. I've seen this on domain controllers and SQL servers that have heavy I/O. The restore triggers a merge of the checkpoint into the parent disk, and if the drive is near full, the merge fails with this error. Sometimes it's a timeout if the VM is busy.

Here's the fix. I'll give you the steps in order. Skip the first step if you already know the VM's VSS state.

Step 1: Check VSS writers inside the VM (if production checkpoint)

1. Log into the VM that's failing. Open a command prompt as Administrator.
2. Run vssadmin list writers and press Enter. You'll see a list of writers and their states.
3. Look for the writer named Microsoft Hyper-V VSS Writer. Its state should show Stable. If it shows Failed or Error, that's your problem.
4. If the writer is failed, run net stop vss then net start vss. This restarts the VSS service. Then run vssadmin list writers again. The state should change to Stable. If not, reboot the VM.

After you do this, expect the VSS writer to show Stable. Then try the checkpoint restore again from the Hyper-V manager.

Step 2: Free up disk space on the host

1. On the Hyper-V host, open File Explorer. Go to the drive where the VM's virtual hard disks are stored. Usually it's D:\ or E:\.
2. Right-click the drive, select Properties. Look at the free space. You need at least 10% free, and for big checkpoints (over 100 GB), you need more like 20% free. The merge process creates a temporary file that's almost the same size as the checkpoint.
3. If you're low on space, delete old backups, move ISO files to another drive, or clear the Recycle Bin. You can also run cleanmgr to clean temporary files.
4. Once you have enough free space, try the restore again.

After cleaning, you should see the free space increase on the drive. Then the restore might work.

Step 3: Check the checkpoint file size and number

1. On the host, go to the folder where the VM's VHDX and AVHDX files are. You'll see files like YourVM.vhdx and YourVM_12345678.avhdx. The .avhdx is the checkpoint.
2. Right-click the .avhdx file, select Properties. Check its size. If it's over 200 GB, the merge can take a long time or fail. You might need to merge it manually using PowerShell.
3. To merge manually, open PowerShell as Administrator on the host. Run this command:

   Get-VM -Name "YourVM" | Get-VMSnapshot | Restore-VMSnapshot -Confirm:$false

   Replace YourVM with your VM's real name. This starts the restore from the command line, which sometimes bypasses GUI timeouts.

After running that, watch the task manager. You should see disk writes and CPU usage on the host. The merge might take 10-30 minutes. Don't close the PowerShell window until it finishes.

Step 4: Increase the VSS timeout (advanced)

1. If the restore still fails, the VSS timeout might be too short. On the host, open regedit as Administrator.
2. Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\VSS\Settings. If the Settings key doesn't exist, create it.
3. Create a new DWORD (32-bit) named TimeoutInSeconds. Set its value to 1800 (that's 30 minutes). Decimal.
4. Close regedit. Restart the VSS service on the host with net stop vss && net start vss.
5. Try the checkpoint restore again.

After this change, the restore has more time to finish. You should see it complete without the error.

If it still fails

Check the Hyper-V event log on the host. Open Event Viewer, go to Applications and Services Logs > Microsoft > Windows > Hyper-V-VMMS > Admin. Look for events with ID 18560 or 18562 around the time of the failure. They'll tell you exactly which file was being written. That might point to a corrupt checkpoint. In that case, delete the checkpoint and create a new one. Also check if the VM is running on a cluster. If it's a cluster, make sure the cluster disk has enough space and is online. I've seen this error when the cluster disk was almost full across all nodes.

One last thing—if the VM is a domain controller, don't take production checkpoints while Active Directory is doing a replication. That's a common trigger. Wait for replication to finish, then do the restore.