| Previous | Next |
| ERROR_KM_DRIVER_BLOCKED | ERROR_PER_USER_TRUST_QUOTA_EXCEEDED |
ERROR_CONTEXT_EXPIRED
The operation attempted to reuse an expired context.
ERROR_CONTEXT_EXPIRED is Win32 error 1931 (0x78B). “Context” is intentionally generic: it may be an authentication, negotiation, enumeration, transaction, or component-specific state object whose validity is bounded by time, session, connection, or protocol progress. The code proves expiration, but not which subsystem owned the context.
How contexts become stale
- a long pause, suspended process, network outage, or clock-sensitive lifetime outlasts the server-side state
- a connection is re-established while the client reuses a handle created for the previous session
- credential renewal, logoff, policy refresh, or service restart invalidates cached negotiation state
- an asynchronous callback arrives after cancellation or after its owner has destroyed the context
- a pool returns an old opaque handle without validating its generation and expiration metadata
Telemetry needed to identify the owner
Record the API or protocol operation, context type and locally assigned correlation ID, creation and last-use timestamps, connection/session generation, service restart counters, cancellation state, and the exact call that returned 1931. Never log raw security handles, tokens, session keys, cookies, or reusable authentication data. Compare monotonic elapsed time where possible so wall-clock adjustments do not distort the timeline.
Diagnosis without guessing the subsystem
Start at the failing call and trace where its context was created. Check the owning API documentation for lifetime and threading rules, then verify whether the underlying connection, credential, transaction, or enumeration was renewed. A generic retry with the same handle cannot restore validity.
Look for a generation mismatch: service restart, reconnect, user switch, policy update, or cancellation between creation and use. In concurrent code, prove that no delayed task can access the context after ownership transfer or teardown.
Recovery pattern
Dispose of the expired context through the owner API when safe, create a fresh context, and restart the protocol at a documented boundary. Replay only operations known to be idempotent; a context may expire after the remote side already accepted an earlier step.
Developers should store generation and expiry information beside opaque handles, invalidate pools on reconnect, and make callbacks hold explicit lifetime ownership. Administrators should investigate recurring early expiration as a sign of restarts, connectivity loss, policy churn, or clock problems.
Difference from an invalid handle
An invalid-handle error says the value is malformed, unknown, or already closed. Error 1931 says a once-valid context has exceeded its usable lifetime, so the remedy is context renewal rather than merely correcting the numeric handle.
Example
A client opens an authenticated session, sleeps through a laptop network transition, and sends the next request using cached session state. The server rejects that state with 1931. Reconnecting and performing a new negotiation succeeds; resending with the expired context never can.
References
- Microsoft: System Error Codes (1700–3999)
- Microsoft: Win32 Error Codes in MS-ERREF
- Microsoft: SSPI context semantics
Looking for a different code? Search another status or error code.