| Previous | Next |
| ERROR_QUOTA_ACTIVITY | ERROR_CALLBACK_INVOKE_INLINE |
ERROR_HANDLE_REVOKED
Access to the specified handle has been revoked.
ERROR_HANDLE_REVOKED is Win32 error 811 (0x32B) and belongs to revocable Windows object handles. The system description identifies the immediate condition but does not identify the caller, object, policy, device, service instance, or transition that produced it.
Interpret this result at the API boundary that returned it. Capture it before logging, cleanup, or another Windows call can replace the thread-local last-error value. Compare the recorded inputs with the documented precondition for revocable Windows object handles rather than starting with a broad system repair.
Where the result appears
- This result can surface during a handle invalidated by a security or isolation boundary.
- This result can surface during brokered access where the owner can revoke a client capability.
- It can surface during a resource that was detached while another component retained a handle.
- It can surface during cleanup after policy, session, container, or device state changed.
Likely causes
- the authority that issued the handle explicitly revoked it.
- the object moved into a state where previously granted access is no longer valid.
- the process kept a stale handle across reconnect or reconfiguration.
- a broker terminated the grant because the client violated policy.
Diagnostic sequence
Diagnosis of it starts with the exact request type: read, write, create, transition, validation, cancellation, or administrative action. Identify the object generation and subsystem owner, then decide whether the failure happened before side effects, during a partial transition, or after completion. This ordering matters in revocable Windows object handles because a blind retry can hide stale state or repeat a non-idempotent change.
- record handle type and the API that originally returned it.
- record issuer or broker identity and revocation event.
- record object lifetime, session, container, and security context.
- record time between handle creation and the failed use.
- record whether a replacement handle can be acquired through the documented path.
Correlate it with the owning component’s operational log, the Windows System log, and any subsystem trace. Telemetry for this Win32 error should preserve native identifiers such as a path or file ID, handle generation, node or peer identity, policy ID, object version, offset and length, or transaction token. Retain decimal 811, hexadecimal 0x32B, and the producing API even when a localized message is also shown.
State boundary to prove
The decisive boundary for this Win32 error is whether the authority that issued the handle explicitly revoked it. Prove or disprove that proposition using handle type and the API that originally returned it together with issuer or broker identity and revocation event. When observations for this Win32 error disagree, preserve both and inspect the transition between them instead of choosing the more convenient value.
A focused validation for this Win32 error should recreate the relevant part of this situation: a broker grants a client access to a protected object, then policy changes revoke the grant. Correct recovery requests a new capability instead of treating the old value as a transient I/O error. The negative case should keep the responsible condition unchanged and confirm error 811; the recovery case should change only that condition and verify a successful result without an unrecorded side effect.
Handling, retry, and recovery
Stop using the revoked value, release dependent state, and reacquire access from the authority that owns the object. Repeating operations on the same numeric handle is unsafe even if the value still looks nonzero.
Retry it only after evidence shows a change in revocable Windows object handles. Initialization, asynchronous completion, recall, or service readiness can justify bounded backoff; malformed metadata, invalid identifiers, policy rejection, unsupported versions, and integrity failures require correction. Before repeating a write or configuration operation after it, query completion state explicitly.
What to log for support and telemetry
- log decimal 811, hexadecimal
0x32B, and the producing API. - log the target object and observed revocable Windows object handles state.
- log caller identity, process and thread IDs, machine or node identity, and UTC time.
- log attempt number, elapsed time, previous result, and any partial side effect.
- retain the first lower-level or component-specific error before Win32 translation.
Difference from nearby codes
A revoked handle is not equivalent to an arbitrary invalid handle; it was once valid and was deliberately withdrawn.
Practical example
A broker grants a client access to a protected object, then policy changes revoke the grant.
Developer and administrator guidance
Code that handles it should keep its Win32 domain visible across exceptions, RPC responses, and JSON or REST wrappers. Administrators should verify the subsystem evidence before changing policy, deleting state, forcing failover, or replacing storage. Recovery is demonstrated only when a test observes 811, changes the responsible condition, and confirms that the same operation succeeds without hidden data loss.
References
- Microsoft: System Error Codes (500–999) — reference for error 811.
- Microsoft: File management functions — reference for error 811.
Looking for a different code? Search another status or error code.