| Previous | Next |
| E_BOUNDS | E_ILLEGAL_STATE_CHANGE |
E_CHANGED_STATE
Concurrent work changed the object state
E_CHANGED_STATE is HRESULT 2147483660 (0x8000000C) from winerror.h. AllStat describes it as “A concurrent or interleaved operation changed the state of the object, invalidating this operation.” In the Windows Runtime metadata, object lifetime, asynchronous operation, activation, and apartment model, the code identifies a specific failure boundary and should not be replaced by a generic COM exception.
The caller should keep this result intact through logging, exception translation, and RPC or language projection boundaries.
Where it is encountered
- C++/WinRT, WRL,.NET projections, or native WinRT ABI calls. Record the interface, method, component version, thread, apartment, process, and correlation ID.
- Runtime-class activation, WinMD reflection, asynchronous objects, observable state, or view lifecycle.
- Cross-thread and cross-apartment handoff between UI, ASTA, STA, MTA, broker, and background work.
The immediate focus for it is an operation whose preconditions were valid when it began but were invalidated by an interleaved mutation, callback, or asynchronous completion. Keep it attached to that operation; the same numeric severity outside the owning API does not supply enough context.
Decisive interpretation boundary
Before choosing recovery, verify that the caller can identify the state generation that changed and can safely rebuild the operation from a fresh snapshot without duplicating effects. Validate this condition for it using the owning API state, not an inferred UI symptom.
Also confirm that all observed objects, tokens, buffers, proxies, metadata files, or ACLs belong to the current operation generation and were not retained from an earlier attempt.
Difference from nearby HRESULTs
It reports invalidation by another transition; E_ILLEGAL_STATE_CHANGE reports that the requested transition itself is forbidden.
A support tool discussing it should name the neighboring result only after the originating API and decisive state are known.
Correct handling and recovery
Discard stale outputs, reacquire current state, and retry only the idempotent portion. Serialize mutations or add generation checks when the same race can recur.
Backoff alone is not a repair for it; a measurable state or configuration transition must justify another attempt.
Practical scenario
A settings page validates a draft while another window commits a newer version. The save detects the version mismatch, reloads the latest document, and asks the user to reconcile changes.
A regression test should reproduce it, assert the raw HRESULT and all relevant outputs, then correct only the decisive condition and verify the intended success or neighboring failure result.
Lifetime, retry, and cleanup rules
After it, determine whether the current object, interface pointer, call context, token, stream, metadata reader, asynchronous operation, or access-control instance remains valid. Release only resources owned by the failing attempt, cancel callbacks through their documented mechanism, and avoid double close, double commit, repeated activation, or replay of a non-idempotent remote method.
The retry policy for it should state the trigger, maximum attempts, cancellation owner, and reconciliation step for effects that may have completed elsewhere.
References
- Microsoft: C++/WinRT error handling
- Microsoft: concurrency and asynchronous operations
- Microsoft: WinMD files
- Microsoft: IAgileObject
- Microsoft: COM apartments
- Microsoft: HRESULT values
Looking for a different code? Search another status or error code.