Mutex Held Across co_await

Load windbg-diagnostic-method first if it is not already loaded in this conversation, and apply it throughout for evidence ranking, hypothesis testing, confidence calibration, independent review, and report validation. This skill adds the bug-family-specific commands and evidence requirements.

Detection

This pattern can occur in native application, service, or user-mode driver code, including UMDF components that use C++ coroutines. Look for a lock acquired before co_await and released after resumption or coroutine destruction. Mutex ownership belongs to the acquiring thread, not the coroutine frame. A resumption on another thread can violate that contract. Even same-thread resumption can create reentrancy or progress problems when the awaited operation needs a lock the coroutine still holds.

Workflow

1. Identify the exact lock primitive and acquisition/release scope in source. Audit every suspension point while the RAII guard or ownership is alive.
2. Establish the acquire and resume threads using trace/source evidence. Standard mutexes and SRW locks do not provide a universally queryable owner field; do not fabricate an owning TID from undocumented layouts.
3. Verify the awaiter's resumption contract. C++/WinRT can preserve apartment context for particular awaitables; resume_background intentionally switches. Do not assume every WinRT awaitable always resumes on a worker or always on the originating thread.
4. Distinguish wrong-thread release, a dependency cycle, state changed during suspension, lifetime failure, and unrelated memory corruption.
5. Move the thread-affine lock into synchronous scopes. Revalidate relevant state after the await rather than treating the pre-await snapshot as current.

If the symptom is general blocking use windbg-user-wait-chain-analysis. For damaged heap objects use windbg-user-heap-corruption-investigation. If a recording is available, windbg-user-ttd-reverse-debugging-triage can help establish the ownership timeline.

Fix pattern

Conceptual sequence, not a promise about any particular scheduler:

under lock:
    take a snapshot and its generation
release lock
await work using that snapshot
under lock on the resumed thread:
    revalidate generation, lifetime, and assumptions
    apply result or explicitly handle a stale/cancelled operation
release lock

Use RAII for each synchronous scope. If invariants cannot tolerate unlocking, redesign the operation or use a specifically designed asynchronous coordination primitive with cancellation/lifetime rules. Switching to a recursive mutex or shared_mutex does not make a thread-affine lock coroutine-safe.

Do not recommend a blanket mutex-type replacement. Shared locking is a separate design decision; changing the primitive does not repair suspension ownership. Keep the object and any captured interfaces alive across asynchronous work.

Validation

• No thread-affine lock ownership survives a suspension in the corrected path.
• Each awaiter's thread/apartment contract is understood.
• State invariants are revalidated after suspension.
• Cancellation, concurrent mutation, shutdown, and failed awaited work are tested.
• The remedy removes the demonstrated cause, not just an observed exception.

References

• Holding a lock across coroutine suspension
• C++/WinRT concurrency and asynchronous operations
• Slim reader/writer locks

Feedback

Follow FEEDBACK.md and report reviewed, sanitized feedback to WinDbg-Feedback. Include windbg-user-mutex-held-across-co-await and the package version from plugin.json; no automatic source, dump, or transcript upload.