Comments on: Crash Dump Analysis Patterns (Part 160) https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/ Structural and Behavioral Patterns for Software Diagnostics, Forensics and Prognostics Tue, 19 May 2026 00:14:15 +0000 http://wordpress.org/?v=2.3.3 By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-767744 Dmitry Vostokov Sat, 15 Nov 2025 19:23:51 +0000 https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-767744 Another example from Windows ARM64: aligned local variable: _Alignas(4096) long long ll = 1; 0:000> dv /V 00000037`30b8e690 @x27+0x1000 ll = 0n-3689348814741910324 00000037`30b8d8c0 @x27+0x0230 align = 8 They are stored indirectly instead: 00007ff6`e7afafdc f9533f69 ldr x9,[x27,#0x2678] 00007ff6`e7afafe0 d2800028 mov x8,#1 00007ff6`e7afafe4 f9000128 str x8,[x9] 0:000> ? @x27+0x2678 Evaluate expression: 237040631048 = 00000037`30b8fd08 0:000> dp 00000037`30b8fd08 L1 00000037`30b8fd08 00000037`30b8d000 0:000> dpp 00000037`30b8fd08 L1 00000037`30b8fd08 00000037`30b8d000 00000000`00000001 Another example from Windows ARM64: aligned local variable:

_Alignas(4096) long long ll = 1;

0:000> dv /V
00000037`30b8e690 @x27+0×1000 ll = 0n-3689348814741910324
00000037`30b8d8c0 @x27+0×0230 align = 8

They are stored indirectly instead:

00007ff6`e7afafdc f9533f69 ldr x9,[x27,#0×2678]
00007ff6`e7afafe0 d2800028 mov x8,#1
00007ff6`e7afafe4 f9000128 str x8,[x9]

0:000> ? @x27+0×2678
Evaluate expression: 237040631048 = 00000037`30b8fd08
0:000> dp 00000037`30b8fd08 L1
00000037`30b8fd08 00000037`30b8d000
0:000> dpp 00000037`30b8fd08 L1
00000037`30b8fd08 00000037`30b8d000 00000000`00000001

]]> By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-767735 Dmitry Vostokov Tue, 07 Jan 2025 19:36:32 +0000 https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-767735 When the Linux crash tool crashes when asked to reconstruct the stack trace from the given RSP, we can dump raw stack data instead and reconstruct the stack trace ourselves. When the Linux crash tool crashes when asked to reconstruct the stack trace from the given RSP, we can dump raw stack data instead and reconstruct the stack trace ourselves.

]]> By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-767712 Dmitry Vostokov Sat, 28 May 2022 21:03:35 +0000 https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-767712 The recent bug is an inability to reconstruct 32-bit stack traces from the WOW64 process in both process and complete memory dumps. The recent bug is an inability to reconstruct 32-bit stack traces from the WOW64 process in both process and complete memory dumps.

]]> By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-767704 Dmitry Vostokov Wed, 24 Nov 2021 09:48:38 +0000 https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-767704 Another command !running is broken in WinDbg 10.0.22000.194 from SDK (but works in 10.0.22473.1005 version from WinDbg Preview): 0: kd> !running GetGlobalValue: unable to get nt!KiSubNodes type size Could not get address of nt!KiSubNodes Could not get idle processor summary. Another command !running is broken in WinDbg 10.0.22000.194 from SDK (but works in 10.0.22473.1005 version from WinDbg Preview):
0: kd> !running
GetGlobalValue: unable to get nt!KiSubNodes type size
Could not get address of nt!KiSubNodes
Could not get idle processor summary.

]]> By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-767703 Dmitry Vostokov Wed, 24 Nov 2021 09:48:19 +0000 https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-767703 WinDbg 10.0.22000.194 (and 10.0.22473.1005) cannot do ".thread /w" command correctly for complete dumps even from Windows 11, I have to revert back to 10.0.20348.1 for my forthcoming training... ; 10.0.22000.194 0: kd> .thread /w ffffc38c2ecd4080 0: kd:x86> k 00 95d80609 00000000 0x6221d056 0: kd:x86> .reload 0: kd:x86> k 00 95d80609 00000000 0x6221d056 ; 10.0.20348.1 0: kd> .thread /w ffffc38c2ecd4080 0: kd:x86> k 00 032bfaa0 74e7e768 0x7657112c 01 032bfad0 74ecb218 0x74e7e768 02 032bfb9c 74ec9f80 0x74ecb218 03 032bfcf8 74ecaa87 0x74ec9f80 04 032bfd80 74ecaaf5 0x74ecaa87 05 032bfda0 000211e4 0x74ecaaf5 06 032bfdd8 0002181a 0x211e4 07 032bfdf4 75bb6823 0x2181a 08 032bfe2c 75ca6739 0x75bb6823 09 032bfe3c 77058aff 0x75ca6739 0a 032bfe94 77058acd 0x77058aff 0b 032bfea4 00000000 0x77058acd 0: kd:x86> .reload 0: kd:x86> k 00 032bfa58 74e7e889 win32u!NtUserWaitMessage+0xc 01 032bfaa0 74e7e768 USER32!DialogBox2+0x10a 02 032bfad0 74ecb218 USER32!InternalDialogBox+0xd7 03 032bfb9c 74ec9f80 USER32!SoftModalMessageBox+0x718 04 032bfcf8 74ecaa87 USER32!MessageBoxWorker+0x314 05 032bfd80 74ecaaf5 USER32!MessageBoxTimeoutW+0x187 06 032bfda0 000211e4 USER32!MessageBoxW+0x45 07 032bfdd8 0002181a AppA+0x11e4 08 032bfdf4 75bb6823 AppA+0x181a 09 032bfe2c 75ca6739 ucrtbase!thread_start<unsigned int (__stdcall*)(void *),1>+0x43 0a 032bfe3c 77058aff KERNEL32!BaseThreadInitThunk+0x19 0b 032bfe94 77058acd ntdll_76ff0000!__RtlUserThreadStart+0x2b 0c 032bfea4 00000000 ntdll_76ff0000!_RtlUserThreadStart+0x1b WinDbg 10.0.22000.194 (and 10.0.22473.1005) cannot do “.thread /w” command correctly for complete dumps even from Windows 11, I have to revert back to 10.0.20348.1 for my forthcoming training…
; 10.0.22000.194
0: kd> .thread /w ffffc38c2ecd4080
0: kd:x86> k
00 95d80609 00000000 0×6221d056
0: kd:x86> .reload
0: kd:x86> k
00 95d80609 00000000 0×6221d056
; 10.0.20348.1
0: kd> .thread /w ffffc38c2ecd4080
0: kd:x86> k
00 032bfaa0 74e7e768 0×7657112c
01 032bfad0 74ecb218 0×74e7e768
02 032bfb9c 74ec9f80 0×74ecb218
03 032bfcf8 74ecaa87 0×74ec9f80
04 032bfd80 74ecaaf5 0×74ecaa87
05 032bfda0 000211e4 0×74ecaaf5
06 032bfdd8 0002181a 0×211e4
07 032bfdf4 75bb6823 0×2181a
08 032bfe2c 75ca6739 0×75bb6823
09 032bfe3c 77058aff 0×75ca6739
0a 032bfe94 77058acd 0×77058aff
0b 032bfea4 00000000 0×77058acd
0: kd:x86> .reload
0: kd:x86> k
00 032bfa58 74e7e889 win32u!NtUserWaitMessage+0xc
01 032bfaa0 74e7e768 USER32!DialogBox2+0×10a
02 032bfad0 74ecb218 USER32!InternalDialogBox+0xd7
03 032bfb9c 74ec9f80 USER32!SoftModalMessageBox+0×718
04 032bfcf8 74ecaa87 USER32!MessageBoxWorker+0×314
05 032bfd80 74ecaaf5 USER32!MessageBoxTimeoutW+0×187
06 032bfda0 000211e4 USER32!MessageBoxW+0×45
07 032bfdd8 0002181a AppA+0×11e4
08 032bfdf4 75bb6823 AppA+0×181a
09 032bfe2c 75ca6739 ucrtbase!thread_start+0×43
0a 032bfe3c 77058aff KERNEL32!BaseThreadInitThunk+0×19
0b 032bfe94 77058acd ntdll_76ff0000!__RtlUserThreadStart+0×2b
0c 032bfea4 00000000 ntdll_76ff0000!_RtlUserThreadStart+0×1b

]]> By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-767702 Dmitry Vostokov Wed, 24 Nov 2021 09:47:55 +0000 https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-767702 A perennial WinDbg feature: to double each line of output after closing the debugging session (q command) and opening a new dump file. A perennial WinDbg feature: to double each line of output after closing the debugging session (q command) and opening a new dump file.

]]> By: Dmitry Vostokov https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-754258 Dmitry Vostokov Thu, 03 Dec 2020 11:30:35 +0000 https://www.dumpanalysis.org/blog/index.php/2011/12/11/crash-dump-analysis-patterns-part-160/#comment-754258 <p align="left">This is the example of a soft variant of Debugger Bug crash dump analysis pattern () but in a different binary media and OS https://arxiv.org/abs/2011.13994</p> This is the example of a soft variant of Debugger Bug crash dump analysis pattern () but in a different binary media and OS https://arxiv.org/abs/2011.13994

]]>