Hyper-V VM Backup Fails with HYPERV38 Error: Checkpoint Creation Fails with Access Denied or VSS Guest Quiescing Error

Problem description

When attempting to back up a Virtual Machine or manually create a checkpoint in a Microsoft Hyper-V environment, the backup job fails with the error HYPERV38.

This issue occurs under two primary scenarios:

File and storage permission restrictions where the Hyper-V Virtual Machine Management Service (VMMS) or Virtual Machine Worker Process (VMWP) lacks access to the virtual disk/checkpoint paths.
Production Checkpoint coordination failures where the hypervisor cannot successfully coordinate with the guest operating system’s Volume Shadow Copy Service (VSS) via Hyper-V Integration Services to quiesce running applications (e.g., Microsoft SQL Server, Exchange) before snapshot creation.

Scenario to Reproduce:

Open Hyper-V Manager.
Right-click on a running Virtual Machine.
Select Checkpoint.
The operation fails with a popup error or a task failure notification.

Cause

The HYPERV38 failure is triggered by one of the following root causes:

Permission Mismatch: The Virtual Machine Worker Process (VMWP) or VM identity lacks full control permissions on the VM configuration files, VHDX files, or checkpoint directories.
Insufficient Storage Space: The host volume hosting the VM or checkpoint files does not have adequate contiguous free space required to generate runtime difference disks (.avhdx).
Existing Metadata Conflicts or Orphaned Checkpoint Trees: Previous snapshot operations left orphaned checkpoints or invalid metadata pointers in the Hyper-V configuration.
Stale / Orphaned Shadow Copies: Host-level or Cluster Shared Volume (CSV)-level VSS snapshots from interrupted prior backup jobs remain active and lock underlying VSS hardware/software providers.
Guest VSS / Integration Service Failure: The vmicvss (Hyper-V Volume Shadow Copy Requestor) service inside the guest OS is stopped, unresponsive, or unable to quiesce guest-level application writers within the timeout window.

Traceback

The backup client or Hyper-V management interface reports:

Plaintext

[HYPERV38] Failed to create checkpoint for virtual machine '<VM_Name>'. Checkpoint creation failed with error: 'General access denied error' (0x80070005).

In the Windows Event Viewer on the Hyper-V host, inspect Applications and Services Logs > Microsoft > Windows > Hyper-V-VMMS > Admin for the following event entries:

Plaintext

Log Name:      Microsoft-Windows-Hyper-V-VMMS-Admin Event ID:      18012 Level:         Error Description:   Checkpoint operation for '<VM_Name>' failed. (Virtual machine ID <VM_GUID>)  Log Name:      Microsoft-Windows-Hyper-V-VMMS-Admin Event ID:      10150 Level:         Error Description:   Could not create the volume snapshot for the virtual machine '<VM_Name>'.                 VSS error inside the guest operating system: 0x80042306 / 0x80042314.

Resolution

1. Verify Permissions and Storage

Ensure the target volume hosting the VM configuration, VHDX, and snapshot files has at least 15–20% free space available.
Confirm that NT VIRTUAL MACHINE\<VM_GUID> or Authenticated Users have full control on the target folder storing the .vhdx and .vmcx files.

2. Check and Clear Stale VSS Shadow Copies (Host & Guest)

On the Hyper-V Host (and inside the Guest VM), open an administrative Command Prompt and inspect writer health:
DOS
```
vssadmin list writers
```
Verification: Ensure that Microsoft Hyper-V VSS Writer (on the host) and standard system writers (inside the guest) show State: [1] Stable with No error.
Check for orphaned shadow copies locking the storage volumes:
DOS
```
vssadmin list shadows
```
Clear stale, unassociated shadow copies causing provider lockups:
DOS
```
vssadmin delete shadows /all /quiet
```

3. Verify Hyper-V Integration Services & Guest Quiescing

Open Hyper-V Manager, right-click the virtual machine, and select Settings.
Under Management, select Integration Services.
Ensure Backup (volume checkpoint) (or Volume Shadow Copy) is checked.
Log in to the Guest OS, open PowerShell as Administrator, and confirm that the guest requestor service is active:
PowerShell
```
Get-Service -Name vmicvss
```
If stopped or disabled, run:
PowerShell
```
Set-Service -Name vmicvss -StartupType Automatic Start-Service -Name vmicvss
```
Diagnostic Isolation Test: In VM Settings > Checkpoints, select Production checkpoints, and enable the fallback checkbox: "Create standard checkpoints if it is not possible to create a production checkpoint". Trigger a backup job or checkpoint creation. If the checkpoint succeeds with this setting enabled, the issue is isolated strictly to guest-level application quiescing/VSS writers rather than host-level storage access.

4. Clear Existing Checkpoint Metadata Conflicts

If previous failed runs left stranded snapshots, open Hyper-V Manager, right-click the VM, and select Delete Checkpoint Subtree if old checkpoints are listed.
If disk merging is pending, allow Hyper-V to merge .avhdx files before re-running the backup.

5. Antivirus and Security Exclusions

Ensure your host-level antivirus / EDR tool excludes the default Hyper-V virtual machine configuration and virtual disk directories (.vhdx, .avhdx, .vmcx, .vmrs).Include and exclude filters

Include: Ensure the VM configuration file path and the VHDX paths are included in any security software "Allow" lists (e.g., Antivirus exclusions).
Exclude: Exclude .avhdx, .vhdx, and .mrt/.vrs files from real-time background virus scanning, as this often causes "Access Denied" locking issues during checkpoint creation.

Verification

Run the following command in PowerShell on the Hyper-V host to confirm manual production checkpoint creation succeeds:
PowerShell
```
Checkpoint-VM -Name "<VM_Name>"
```
Check Hyper-V Manager to verify the checkpoint appears under the VM hierarchy without an Access Denied prompt.

Remove the test checkpoint via:

PowerShell

Get-VMSnapshot -VMName "<VM_Name>" | Remove-VMSnapshot

Re-run the Druva backup job from the Druva Management Console and verify the job status updates to Successful.