What does Windows error code 1131 (ERROR_POSSIBLE_DEADLOCK) mean?

 
Previous Next
ERROR_NOT_ENOUGH_SERVER_MEMORY ERROR_MAPPED_ALIGNMENT

ERROR_POSSIBLE_DEADLOCK

A potential deadlock condition has been detected.

ERROR_POSSIBLE_DEADLOCK is Win32 error 1131 (0x46B). It is the Win32 form of a possible-deadlock condition. One documented source is a critical-section wait that exceeds the system deadlock timeout, where EnterCriticalSection can raise EXCEPTION_POSSIBLE_DEADLOCK or STATUS_POSSIBLE_DEADLOCK. The code is a debugging signal, not an invitation to catch the exception and continue as if synchronization were healthy.

What may be happening

  • two or more threads hold locks in conflicting order and form a circular wait
  • a thread waits on a critical section owned by a thread that is blocked on I/O, COM, a window message, or another process
  • a lock owner exited, corrupted state, or stopped making progress
  • loader-lock or DllMain activity participates in the wait chain
  • the wait is extremely long but not truly circular, revealing a hang or starvation problem

The word “possible” matters because a timeout proves lack of progress, not necessarily a perfect two-lock cycle. Either way, production code should preserve the process state for analysis instead of retrying the same lock acquisition blindly.

Evidence to capture immediately

  • a full user-mode process dump with all thread stacks
  • the waiting thread, lock address, owning thread, and recursion count when available
  • wait-chain traversal output and blocked COM or window-message dependencies
  • recent lock acquisitions, request IDs, and operations held across the wait
  • Application Verifier or debugger output if lock checks are enabled

A log line with only error 1131 is rarely enough. Thread IDs, lock identity, owner stack, and the operation protected by the lock turn the symptom into an actionable lock-order or blocking-call defect.

Debugging sequence

  • inspect every thread and identify who owns the object awaited by the failing thread
  • follow that owner’s waits until the chain terminates or returns to an earlier thread
  • check for locks held across synchronous I/O, callbacks, COM calls, SendMessage, or process shutdown
  • enable Application Verifier lock and hang checks on a reproducible test build
  • document a global lock order and verify every conflicting path against it

Do not change the critical-section timeout merely to suppress the report. A longer timeout delays detection while leaving the underlying cycle or unbounded blocking call in place.

Corrective design

Acquire multiple locks in one consistent order, minimize work while a lock is held, and avoid calling unknown or reentrant code under synchronization. Separate state protection from slow I/O. Where cancellation is required, design it so the cancelling thread does not wait for a worker while holding a lock that the worker needs to exit.

If the process must recover operationally, terminate and restart it after collecting a dump. Continuing from a caught possible-deadlock exception can leave ownership and protected invariants uncertain.

Related conditions

WAIT_TIMEOUT can be an expected bounded wait chosen by application code. Error 1131 is associated with system deadlock detection and deserves debugging. A high-CPU livelock may show no blocking chain at all even though the application also makes no useful progress.

Example

Thread A holds a configuration lock and sends a synchronous message to the UI thread. The UI thread is handling shutdown and waits for a worker that needs the same configuration lock. The critical-section wait eventually produces 1131. Reordering shutdown and removing synchronous UI calls under the lock fixes the cycle; increasing the timeout only hides it longer.

References

Looking for a different code? Search another status or error code.