Crash Dump Analysis (Part 42j)
This is an additional variation of the general Wait Chain pattern where mutexes (mutants) are involved in thread wait chains, for example:
THREAD fffffa8019388b60 Cid 02e8.cfd0 Teb: 000007fffffa2000 Win32Thread: 0000000000000000 WAIT: (UserRequest) UserMode Non-Alertable
fffffa800d75daf0 Mutant - owning thread fffffa800ea2ab60
[...]
THREAD fffffa8016abab60 Cid 02e8.ec34 Teb: 000007fffffae000 Win32Thread: 0000000000000000 WAIT: (UserRequest) UserMode Non-Alertable
fffffa800d75daf0 Mutant - owning thread fffffa800ea2ab60
[...]
We have seen such dependencies in various previous pattern interaction case studies such as:
- Inconsistent dump, blocked threads, wait chains, incorrect stack trace and process factory
- Semantic Split pattern example
- Insufficient memory, handle leak, wait chain, deadlock, inconsistent dump and overaged system
- Blocked GUI thread, wait chain and virtualized process
- LPC/ALPC Wait Chain pattern example
- Mixed object Deadlock pattern example
- LPC Deadlock pattern example
Another example I show here is an unusual number of mutant dependencies in one complete memory dump from hang system:
AppA(KTHREAD-1) -> AppB(KTHREAD-2)
AppB(KTHREAD-3) -> ServiceA(KTHREAD-4)
AppA(KTHREAD-5) -> ServiceA(KTHREAD-4)
AppB(KTHREAD-6) -> AppA(KTHREAD-7)
AppB(KTHREAD-6) -> AppC(KTHREAD-8)
AppC(KTHREAD-9) -> ServiceA(KTHREAD-4)
AppC(KTHREAD-10) -> AppB(KTHREAD-11)
Here the notation AppX(N)->AppY(M) means that a thread N from AppX process is waiting for a mutant that is owned by a thread M from AppY process. Because AppB, AppC and ServiceA belonged to the Same Vendor it was advised to check with that ISV.
- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -