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 -

3 Responses to “Crash Dump Analysis Patterns (Part 219)”

  1. Adam.Beraxa Says:

    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.

  2. Dmitry Vostokov Says:

    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.

  3. Dmitry Vostokov Says:

    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

Leave a Reply

You must be logged in to post a comment.