Comments on: Crash Dump Analysis Patterns (Part 16a)

By: Dmitry Vostokov

Dmitry Vostokov — Tue, 03 Jun 2025 12:37:18 +0000

We can check Execution Residue of the interrupt stack:

0: kd> !idt 8

Dumping IDT: fffff8012ae84000

08: fffff80124812540 nt!KiDoubleFaultAbortShadow Stack = 0xFFFFF8012AE883D0

0: kd> dp 0xFFFFF8012AE883D0
fffff801`2ae883d0 fffff801`225c1000 fffff801`2aeacfe0
fffff801`2ae883e0 fffff801`225c1000 00000000`b41ed002
fffff801`2ae883f0 00000000`00000000 00000000`00000000
fffff801`2ae88400 00000000`00000000 00000000`00000000
fffff801`2ae88410 00000000`00000000 00000000`00000000
fffff801`2ae88420 00000000`00000000 00000000`00000000
fffff801`2ae88430 00000000`00000000 00000000`00000000
fffff801`2ae88440 00000000`00000000 00000000`00000000

0: kd> dpS fffff801`2aeacfe0-6000 L6000/8
fffff801`2b002731 BasicDisplay!CopyBitsTo_4+0×3c1
fffff801`2b0011b6 BasicDisplay!BltBits+0×136
fffff801`241aac49 nt!FioFwReadBytesAtOffset+0×1d
fffff801`2b002052 BasicDisplay!BASIC_DISPLAY_DRIVER::SystemDisplayWrite+0×116
fffff801`2b0020c4 BasicDisplay!BddDdiSystemDisplayWrite+0×24
fffff801`24a13260 nt!BcpWorkspace
fffff801`2bbb18fd dxgkrnl!DpiSystemDisplayWrite+0xdd
fffff801`241992b0 nt!GxpWriteFrameBufferPixels+0×1f8
fffff801`241d2485 nt!output_l+0×819
fffff801`241c5eee nt!KiFlushRangeTb+0×7e
fffff801`24187463 nt!IoFlushAdapterBuffers+0×33
fffff801`2c5f3601 dump_lsi_sas!BuildScatterGather+0×5
fffff801`2418b7b9 nt!HalpHvCounterQueryCounter+0×19
fffff801`241c5e4a nt!KeFlushMultipleRangeCurrentTb+0xbe
fffff801`2c5c3812 dump_diskdump!ScsiPortNotification+0×172
fffff801`241b4399 nt!KeFlushCurrentTbOnly+0×61
fffff801`2c5f36cc dump_lsi_sas!BuildScatterGather+0xd0
fffff801`2c5f3046 dump_lsi_sas!LSImpiBuildIo+0×176
fffff801`2c5c1c61 dump_diskdump!StartIo+0xa5
fffff801`2c5c1d6f dump_diskdump!ExecuteSrb+0×1f
fffff801`243317f9 nt!MmIsAddressValid+0×9
fffff801`2c5c2264 dump_diskdump!DiskDumpWrite+0×1d4
fffff801`2b139a00 crashdmp!GetStorageDumpIoMode+0×14
fffff801`2b13934d crashdmp!CrashdmpWriteRoutine+0×9d
fffff801`2b140b70 crashdmp!Context+0×50
fffff801`2b138dfe crashdmp!WritePageSpanToDisk+0×31a
fffff801`2b140b70 crashdmp!Context+0×50
fffff801`2b1392b0 crashdmp!CrashdmpWriteRoutine
fffff801`2b139100 crashdmp!CrashdmpWritePendingRoutine
fffff801`2b140b70 crashdmp!Context+0×50
fffff801`2b13b456 crashdmp!FindNextSetBitRange64+0xd6
fffff801`2b140b70 crashdmp!Context+0×50
fffff801`2b137b1f crashdmp!WriteBitmapDump+0×477
fffff801`242f3b90 nt!HvlGetEncryptedData
fffff801`2b140b70 crashdmp!Context+0×50
fffff801`242f3b90 nt!HvlGetEncryptedData
fffff801`242f3b90 nt!HvlGetEncryptedData
fffff801`24312bd0 nt!KiBugCheckProgress
fffff801`2b140b70 crashdmp!Context+0×50
fffff801`2b13695c crashdmp!DumpWrite+0×474
fffff801`2b140b70 crashdmp!Context+0×50
fffff801`24312bd0 nt!KiBugCheckProgress
fffff801`2b13c123 crashdmp!CrashdmpTelemetrySaveEnvironmentVariable+0×5f
fffff801`2b13290d crashdmp!CheckContextIntegrity+0×6d
fffff801`24312bd0 nt!KiBugCheckProgress
fffff801`2b1350d6 crashdmp!CrashdmpWrite+0×1f6
fffff801`24312bd0 nt!KiBugCheckProgress
fffff801`242fdf0e nt!IoWriteCrashDump+0×53e
fffff801`241c6b1a nt!IopIsAddressRangeValid+0×3e
fffff801`242fd6d0 nt!IoSetDumpRange
fffff801`242fd060 nt!IoFreeDumpRange
fffff801`25492794 myfault+0×2794
fffff801`24312456 nt!KeBugCheck2+0xca6
fffff801`24a31a00 nt!KeBugCheckReasonCallbackListHead
fffff801`24a31a00 nt!KeBugCheckReasonCallbackListHead
fffff801`25492794 myfault+0×2794
fffff801`24312bd0 nt!KiBugCheckProgress
fffff801`24312bd0 nt!KiBugCheckProgress
fffff801`25492794 myfault+0×2794
fffff801`241f71c0 nt!KeBugCheckEx
fffff801`241f72c7 nt!KeBugCheckEx+0×107
fffff801`25492794 myfault+0×2794
fffff801`24209169 nt!KiBugCheckDispatch+0×69
fffff801`25492794 myfault+0×2794
fffff801`24203f83 nt!KiDoubleFaultAbort+0×2c3
fffff801`25491d3e myfault+0×1d3e
fffff801`25490000 myfault
fffff801`25492794 myfault+0×2794

By: Dmitry Vostokov

Dmitry Vostokov — Fri, 01 Oct 2021 19:04:01 +0000

0: kd> !stackusage
Stack Usage By Function
===============================

Size Count Module
0×00005970 477 myfault
0×00000140 1 nt!KiBugCheckDispatch
0×00000140 1 nt!IopXxxControlFile
0×00000140 1 myfault
0×000000A0 1 nt!IopSynchronousServiceTail
0×00000070 1 nt!NtDeviceIoControlFile
0×00000060 1 myfault
0×00000040 1 nt!IofCallDriver
0×00000030 1 myfault
0×00000008 2 nt!KeBugCheckEx

Total Size: 0×00005F18
[…]

By: Crash Dump Analysis » Blog Archive » Old Mental Dumps from June 21st

Crash Dump Analysis » Blog Archive » Old Mental Dumps from June 21st — Mon, 21 Jun 2010 11:07:31 +0000

[…] • Crash Dump Analysis Patterns (Part 16a) - Stack overflow in kernel. Generated some comments and can also be see in the following pattern case study: Lateral damage, stack overflow and execution residue […]

By: Crash Dump Analysis » Blog Archive » Icons for Memory Dump Analysis Patterns (Part 31)

Tue, 04 May 2010 10:37:53 +0000

[…] we introduce an icon for Stack Overflow (kernel mode) […]

By: Dmitry Vostokov

Dmitry Vostokov — Sun, 07 Mar 2010 23:42:09 +0000

Certain functions like RtlDispatchException, RtlRaiseStatus and others have function parameters pointing to an exception record and context. See, for example,

http://source.winehq.org/source/dlls/kernel32/except.c#L84

By: Finy

Finy — Sun, 07 Mar 2010 04:53:15 +0000

I have the same question as Blue Fish had(June 24th, 2008 at 3:44 am) :

May I know why to choose “b044ef44″ & “b044ec74″ to inspect?

By: Crash Dump Analysis » Blog Archive » Variable Kernel Stack in Vista and W2K8

Thu, 19 Mar 2009 21:58:49 +0000

[…] Stack Overflow Pattern (kernel mode) […]

By: Crash Dump Analysis » Blog Archive » Lateral damage, stack overflow and execution residue: pattern cooperation

Wed, 05 Nov 2008 17:39:53 +0000

[…] bugcheck argument 1 shows that we have a double fault that most often results from kernel stack overflow. If we go back to processor 0 to inspect its TSS we don’t get meaningful results too (we […]

By: Dmitry Vostokov

Dmitry Vostokov — Tue, 24 Jun 2008 07:39:33 +0000

I chose b044e000 because I wanted to inspect the raw stack data from the top of the stack (ESP value in red above). By choosing other ranges we might miss something.

By: Blue Fish

Blue Fish — Tue, 24 Jun 2008 03:44:59 +0000

According to the result of : dds b044e000 b044e000+3000
May I know whay to choose “b044ef44″ & “b044ec74″ to inspect? Does we need to choose the value of “RtlRaiseStatus+0×47″ after? How about if I can’t find “RtlRaiseStatus+0×47″?

Thanks!