Crash Dump Analysis Patterns (Part 219)
To complement Module patterns sub-catalogue we introduce Origin Module pattern. This is a module that may have originated the problem behavior. For example, when we look at a stack trace we may skip Top Modules due to our knowledge of the product, for example, if they are not known as Problem Modules or known as Well-Tested Modules. In case of Truncated Stack Traces we may designate bottom modules as possible problem origins. For example, for Reference Leak pattern example we may consider checking reference counting for selected modules such as ModuleA and ModuleB:
ad377ae8 +1 Dflt nt! ?? ::FNODOBFM::`string'+18f1d
nt!ObpCallPreOperationCallbacks+4e
nt!ObpPreInterceptHandleCreate+af
nt! ?? ::NNGAKEGL::`string'+2c31f
nt!ObOpenObjectByPointerWithTag+109
nt!PsOpenProcess+1a2
nt!NtOpenProcess+23
nt!KiSystemServiceCopyEnd+13
nt!KiServiceLinkage+0
ModuleA+dca63
ModuleA+b5bc
ModuleA+c9c2e
ModuleA+bae56
ModuleA+b938d
ModuleA+c0ec6
ModuleA+afce7
ad377aeb -1 Dflt nt! ?? ::FNODOBFM::`string'+4886e
nt!ObpCallPreOperationCallbacks+277
nt!ObpPreInterceptHandleCreate+af
nt! ?? ::NNGAKEGL::`string'+2c31f
nt!ObOpenObjectByPointerWithTag+109
nt!PsOpenProcess+1a2
nt!NtOpenProcess+23
nt!KiSystemServiceCopyEnd+13
nt!KiServiceLinkage+0
ModuleA+dca63
ModuleA+b5bc
ModuleA+c9c2e
ModuleA+bae56
ModuleA+b938d
ModuleA+c0ec6
ModuleA+afce7
ad377af7 +1 Dflt nt! ?? ::NNGAKEGL::`string'+1fb41
nt!ObReferenceObjectByHandle+25
ModuleA+dcade
ModuleA+b5bc
ModuleA+c9c2e
ModuleA+bae56
ModuleA+b938d
ModuleA+c0ec6
ModuleA+afce7
ModuleA+87ca
ModuleA+834a
ModuleA+a522c
ModuleA+a51b6
ModuleA+a4787
ModuleB+19c0c
ModuleB+19b28
ad377afa -1 Dflt nt! ?? ::FNODOBFM::`string'+4886e
ModuleA+dcbbe
ModuleA+b5bc
ModuleA+c9c2e
ModuleA+bae56
ModuleA+b938d
ModuleA+c0ec6
ModuleA+afce7
ModuleA+87ca
ModuleA+834a
ModuleA+a522c
ModuleA+a51b6
ModuleA+a4787
ModuleB+19c0c
ModuleB+19b28
ModuleB+b652
- Dmitry Vostokov @ DumpAnalysis.org + TraceAnalysis.org -
July 17th, 2017 at 1:27 pm
How to interpret this output with regards to reference tracking? I have not found a conclusive method (is the module count dividable by 2, so is it a reference and a de-reference?) or interpretation, and documentation is almost non-existent.
July 20th, 2017 at 11:07 pm
As far as I understand the balanced reference counting should cancel +1 and -1. In such a case the object should be deleted. If it still exists then we still have the excess of +1. The stack traces will reveal the possible modules that may have forgotten to dereference the object.
May 6th, 2021 at 6:21 pm
The same Top Module and Origin Module in both Stack Trace and Interrupt Stack:
2: kd> ~0;kc
# Call Site
00 nvlddmkm
01 nvlddmkm
02 nvlddmkm
03 nvlddmkm
04 nvlddmkm
05 nvlddmkm
06 nvlddmkm
07 nvlddmkm
08 nvlddmkm
09 nvlddmkm
0a nvlddmkm
0b nvlddmkm
0c nvlddmkm
0d nvlddmkm
0e nvlddmkm
0f nvlddmkm
10 nvlddmkm
11 nt!KiExecuteAllDpcs
12 nt!KiRetireDpcList
13 nt!KxRetireDpcList
14 nt!KiDispatchInterruptContinue
15 nt!KiDpcInterruptBypass
16 nt!KiInterruptDispatch
17 nt!KzLowerIrql
18 nvlddmkm
19 nvlddmkm
1a nvlddmkm
1b nvlddmkm
1c nvlddmkm
1d nvlddmkm
1e nvlddmkm
1f dxgkrnl!DpiDxgkDdiSetPowerState
20 dxgkrnl!DpiFdoSetAdapterPowerState
21 dxgkrnl!DpiFdoHandleDevicePower
22 dxgkrnl!DpiFdoDispatchPower
23 dxgkrnl!DpiDispatchPower
24 nvlddmkm
25 nvlddmkm
26 nt!PopIrpWorker
27 nt!PspSystemThreadStartup
28 nt!KiStartSystemThread