| Previous | Next |
| CONTEXT_E_NOCONTEXT | CONTEXT_E_SYNCH_TIMEOUT |
CONTEXT_E_WOULD_DEADLOCK
CONTEXT_E_WOULD_DEADLOCK is the failure HRESULT 0x8004E005 (signed decimal -2147164155, unsigned decimal 2147803141). Its severity bit is 1, facility is 4 (FACILITY_ITF), and the facility-specific code field is 0xE005.
The proposed synchronized call closes a COM+ activity lock cycle
COM+ returns this HRESULT when a component uses synchronization and the runtime determines that a method call would deadlock. The rejection is preventive: the target method may never begin executing.
AllStat describes the result as “The component is configured to use synchronization and this method call would cause a deadlock to occur.” for it, this wording identifies the immediate COM+ condition, while surrounding context and earlier events determine why it was reached.
Contract boundary
The important object is the COM+ activity and its synchronization lock chain. The same interface call might succeed from another activity yet fail from a nested callback or circular cross-context route that attempts to reacquire an incompatible lock.
Causes that fit this specific result
- A synchronized component calls another component that synchronously calls back into the first activity.
- Two activities acquire synchronized contexts in opposite order.
- A component waits for worker completion while the worker needs to enter the blocked COM+ context.
- A cross-apartment or remote callback turns an apparently linear call into a lock cycle.
Evidence to preserve before changing the system
- Capture activity IDs, context IDs, thread IDs, call direction, and the first synchronized entry held by each thread.
- Collect a process dump with COM/RPC stacks before retrying or terminating the application.
- Record component synchronization settings and whether each activation is Required or Requires New.
- Trace callbacks and event sinks because the cycle may not be visible in the initiating stack alone.
Diagnostic sequence
- Draw the complete synchronous call graph across COM+ contexts and identify the edge that returns to a held activity.
- Remove blocking waits or move callbacks outside the synchronized call boundary.
- Apply a consistent acquisition order when multiple synchronized services must be called.
- Use asynchronous messaging only when transaction and ordering semantics are deliberately redesigned.
Retry and recovery
Break the lock cycle in component design or call ordering. Repeating the identical synchronous call graph is deterministic and should not be treated as a transient retry.
What the result does not establish
The code does not identify the exact pair of locks and does not prove ordinary native mutex deadlock. It specifically reports a COM+ synchronization decision.
Difference from nearby HRESULT values
CONTEXT_E_SYNCH_TIMEOUT reports waiting that exceeded an allowed interval rather than a cycle detected before entry. CO_E_NOSYNCHRONIZATION reports missing required synchronization configuration.
Practical scenario
Component A holds its synchronized context and calls B. B invokes a synchronous status callback on A before returning. COM+ detects that the callback would reenter the held activity and rejects it; the callback is moved after B completes.
Developer and telemetry guidance
Include activity and context IDs in distributed traces. A thread-only trace is insufficient because COM+ synchronization follows activity relationships across apartments and processes.
Official Microsoft references
- Microsoft: COM transaction and context error codes
- Microsoft: COM+ synchronization concepts
- Microsoft: COM+ contexts
- Microsoft: COM+ troubleshooting
- Microsoft: HRESULT values in MS-ERREF
Looking for a different code? Search another status or error code.