Comments on: Crash Dump Analysis Patterns (Part 219) https://www.dumpanalysis.org/blog/index.php/2015/02/07/crash-dump-analysis-patterns-part-219/ Structural and Behavioral Patterns for Software Diagnostics, Forensics and Prognostics Wed, 06 May 2026 00:21:43 +0000 http://wordpress.org/?v=2.3.3 By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2015/02/07/crash-dump-analysis-patterns-part-219/#comment-766911 Dmitry Vostokov Thu, 06 May 2021 18:21:31 +0000 https://www.dumpanalysis.org/blog/index.php/2015/02/07/crash-dump-analysis-patterns-part-219/#comment-766911 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 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

]]> By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2015/02/07/crash-dump-analysis-patterns-part-219/#comment-741740 Dmitry Vostokov Thu, 20 Jul 2017 23:07:22 +0000 https://www.dumpanalysis.org/blog/index.php/2015/02/07/crash-dump-analysis-patterns-part-219/#comment-741740 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. 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.

]]> By: Adam.Beraxa https://www.dumpanalysis.org/blog/index.php/2015/02/07/crash-dump-analysis-patterns-part-219/#comment-741739 Adam.Beraxa Mon, 17 Jul 2017 13:27:00 +0000 https://www.dumpanalysis.org/blog/index.php/2015/02/07/crash-dump-analysis-patterns-part-219/#comment-741739 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. 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.

]]>