| Previous | Next |
| E_CHANGED_STATE | E_ILLEGAL_METHOD_CALL |
E_ILLEGAL_STATE_CHANGE
Requested transition is not permitted
E_ILLEGAL_STATE_CHANGE is HRESULT 2147483661 (0x8000000D) from winerror.h. AllStat describes it as “An illegal state change was requested.” 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.
Handling this result correctly requires the code-specific postcondition, not merely the fact that FAILED(hr) is true.
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 a state-machine transition that is structurally invalid from the object current state, such as reopening a terminal object or committing before preparation. 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 current state and allowed transition table are known from the owning API rather than guessed from UI labels. 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.
Correct handling and recovery
Do not force the transition. Move through the documented intermediate states or create a new object when the current instance is terminal.
Backoff alone is not a repair for it; a measurable state or configuration transition must justify another attempt.
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.
Practical scenario
A media session receives a request to return from Closed to Running. The controller creates a new session and reattaches sources instead of mutating the closed instance.
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.
Difference from nearby HRESULTs
It rejects a transition; E_ILLEGAL_METHOD_CALL rejects a method invocation at the current time even when no explicit state mutation was requested.
Merging it with the neighboring HRESULT would choose the wrong retry, recreation, authorization, or cleanup path.
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.