HRESULT 0x80042463 (VDS_E_RETRY): meaning and diagnosis

Status / error code:

Category:

Constant name:

Source:

Facility:

Operating System:

Description:

VDS explicitly requests that the failed storage operation be retried after its transient condition has cleared.

Previous	Next
VDS_E_REVERT_ON_CLOSE_MISMATCH	VDS_E_ONLINE_PACK_EXISTS

VDS_E_RETRY

VDS_E_RETRY is the failure HRESULT 0x80042463 (signed decimal -2147212189, unsigned decimal 2147755107). Its severity bit is set, the facility field is 4 (FACILITY_ITF), and the facility-specific code field is 0x2463.

VDS reports a retryable failure, but the retry still needs a state check

The published description says that the operation failed and should be retried. This is an explicit retry signal rather than a generic recommendation inferred from an unknown error. It remains a failure HRESULT, so no caller should assume that the requested storage change completed.

Where the failure boundary lies

The code says less about the root cause than most VDS errors but more about recovery policy: the service expects that the condition can change. It differs from VDS_E_ANOTHER_CALL_IN_PROGRESS, which identifies concurrency, and from VDS_E_OPERATION_PENDING or VDS_S_IN_PROGRESS, which describe work that has not finished rather than a completed failed attempt.

Likely causes to separate

A transient provider or driver state prevented the operation at that moment.
Enumeration or cache synchronization had not yet caught up with a recent storage change.
A temporary resource, lock, or device readiness condition made the current attempt unsuitable.
The service detected a short-lived ordering condition for which replay is the intended caller behavior.

Evidence worth preserving

Record the attempt number, elapsed time, target object identity, and properties observed immediately before each retry.
For asynchronous APIs, retain both the method-call HRESULT and the final result returned through IVdsAsync::Wait.
Capture notifications between attempts so that a successful retry can be associated with the state change that enabled it.
Log whether the previous attempt produced any visible partial effect, such as a newly created object or changed status.

Diagnostic sequence

Requery the target before replaying the call; object IDs and ownership can change while the transient condition clears.
Use bounded backoff instead of a tight loop that competes with provider recovery or bus enumeration.
Stop retrying when the object disappears, enters a failed state, or a more specific HRESULT replaces this value.
For destructive work, verify idempotency. A timeout followed by VDS_E_RETRY does not guarantee that no lower-layer change occurred.

Retry and recovery

A safe policy is a small, bounded number of retries with increasing delay and a fresh property query before every attempt. Re-enumeration is appropriate only when device arrival or removal is suspected; refresh is appropriate when existing-object properties appear stale. Do not call either operation reflexively after every retry signal.

What this HRESULT does not establish

This HRESULT does not promise that the next attempt will succeed, identify a required delay, or guarantee absence of partial side effects. It also does not authorize retrying with a different disk selected by ordinal position after the topology changes.

Practical example

A newly presented disk appears in Plug and Play while the provider is still updating its object model. The first configuration call returns VDS_E_RETRY. The application waits, receives an arrival notification, re-enumerates, resolves the disk by stable identity, and then repeats the operation once.

Guidance for software and telemetry

Expose retry count and the state transition that preceded each attempt. Silent infinite retry turns a useful transient signal into an unexplained hang and can be dangerous for storage operations whose completion is not strictly atomic.

Official Microsoft references

Looking for a different code? Search another status or error code.