What does HRESULT 0x80042405 (VSS_E_ASRERROR_SHARED_CRIDISK) mean?

VSS_E_ASRERROR_SHARED_CRIDISK

A critical ASR volume is on unsupported cluster-shared storage. Automated System Recovery has identified a critical volume on a cluster shared disk. The documented contract marks this configuration unsupported; it is a topology veto rather than a transient snapshot-provider delay.

The documented condition is: “Automated System Recovery failed the shadow copy, because a selected critical volume is located on a cluster shared disk. This is an unsupported configuration.”

Where VSS_E_ASRERROR_SHARED_CRIDISK appears

The check occurs when ASR determines which volumes are critical to the bootable system state and validates whether their hosting disks can participate in the requested disaster-recovery snapshot.

Likely causes

• A boot-critical or system-state volume was placed on storage managed as a Cluster Shared Volume or equivalent shared cluster disk.
• The backup selection accidentally classifies a shared disk as part of the local machine critical set.
• Cluster storage ownership or presentation makes a disk appear local while ASR still recognizes it as shared.
• A recovery design assumes node-level ASR can capture cluster-shared application data with the same semantics as local critical disks.

Evidence to capture before changing storage

• Map each selected critical volume to its physical disk, cluster resource and CSV path.
• Capture cluster storage configuration and ownership at the time the backup is prepared.
• Record the ASR critical-volume list separately from ordinary data-volume selections.
• Preserve the VSS event containing the disk or volume identity that triggered the veto.

Diagnostic sequence

• Confirm that the reported volume is genuinely required for local bare-metal recovery.
• Distinguish the node operating-system disks from clustered application or data disks.
• Review whether a cluster-aware backup mechanism is responsible for the shared storage.
• Do not attempt repeated snapshots while the unsupported placement is unchanged.

Recovery and retry

Use a supported architecture: keep node-critical volumes on eligible local storage, or exclude noncritical shared data from the ASR critical set and protect it with cluster-aware backup. Retry only after the storage role or backup scope has been corrected.

What this HRESULT does not prove

The result does not say the cluster disk is offline, unhealthy or inaccessible. A perfectly functioning shared disk can still be invalid for this ASR operation.

Difference from nearby VSS results

VSS_E_CRITICAL_VOLUME_ON_INVALID_DISK is broader and covers other disk types that ASR cannot back up. This value identifies cluster-shared placement specifically.

Practical example

A clustered server stores a volume classified as critical on CSV storage. VSS can access the volume, but the ASR writer refuses to include it in node bare-metal recovery because the configuration is unsupported.

Guidance for backup software and telemetry

Backup products should present this as a design incompatibility and name the cluster resource. Automatic retry wastes time and can conceal the need for separate cluster-data protection.

Official Microsoft references

• Microsoft: VSS Automated System Recovery for disaster recovery
• Microsoft: Cluster Shared Volumes overview
• Microsoft: the VSS requester, writer and provider model
• Microsoft: VSS writers and their lifecycle