<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.3.3" -->
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	>
<channel>
	<title>Comments on: Crash Dump Analysis Patterns (Part 41a)</title>
	<link>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/</link>
	<description>Structural and Behavioral Patterns for Software Diagnostics, Forensics and Prognostics</description>
	<pubDate>Wed, 06 May 2026 06:51:29 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.3.3</generator>
		<item>
		<title>By: Dmitry Vostokov</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-767748</link>
		<dc:creator>Dmitry Vostokov</dc:creator>
		<pubDate>Sat, 31 Jan 2026 10:46:39 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-767748</guid>
		<description>The stack trace from USB-keyboard generated dump on Windows 11 ARM64

MANUALLY_INITIATED_CRASH (e2)
The user manually initiated this crash dump.
Arguments:
Arg1: 0000000000000000
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000

0: kd&gt; kc
 # Call Site
00 nt!KeBugCheck2
01 nt!KeBugCheckEx
02 kbdhid!KbdHidProcessCrashDump
03 kbdhid!KbdHid_InsertCodesIntoQueue
04 HIDPARSE!HidP_ModifierCode
05 HIDPARSE!HidP_TranslateUsageAndPagesToI8042ScanCodes
06 kbdhid!KbdHid_ReadComplete
07 nt!IopUnloadSafeCompletion
08 nt!IopfCompleteRequest
09 HIDCLASS!HidpDistributeInterruptReport
0a HIDCLASS!HidpInterruptReadComplete
0b nt!IopfCompleteRequest
0c Wdf01000!FxIrp::CompleteRequest
0d Wdf01000!FxRequest::CompleteInternal
0e Wdf01000!FxRequest::Complete
0f Wdf01000!imp_WdfRequestComplete
10 USBXHCI!Bulk_ProcessTransferEventWithED1
11 USBXHCI!Bulk_EP_TransferEventHandler
12 USBXHCI!Endpoint_TransferEventHandler
13 USBXHCI!Interrupter_DeferredWorkProcessor
14 Wdf01000!FxInterrupt::DpcHandler
15 Wdf01000!FxInterrupt::_InterruptDpcThunk
16 nt!KiExecuteAllDpcs
17 nt!KiRetireDpcList
18 nt!KxPlatformSwapStacksAndCall
19 nt!KiPlatformSwapStacksAndCallReturn
1a nt!KiDispatchInterrupt
1b nt!HalpInterruptCheckForSoftwareInterrupt
1c nt!KiInterruptException
1d nt!KiUserInterruptHandler
1e ntdll!RtlpHpTagFreeHeap
1f ntdll!RtlFreeHeap
20 msvcrt!free
21 diagperf!XPerfCore::CPathNode::`scalar deleting destructor'
22 diagperf!XPerfCore::CPathNode::Insert
23 diagperf!XPerfCore::CPathNode::Insert
24 diagperf!XPerfCore::CPathNode::Insert
25 diagperf!XPerfCore::CPathNode::Insert
26 diagperf!XPerfAddIn::CProcessInfoSource::ImageEvent
27 diagperf!XPerfAddIn::CProcessInfoSource::OnEvent
28 diagperf!XPerfCore::CSession::OnEventRecord
29 diagperf!XPerfCore::CSession::EventRecordCallback
2a diagperf!XPerfCore::CEtwTrace::EventRecordCallback
2b sechost!EtwpProcessTraceLog
2c sechost!ProcessTrace
2d diagperf!XPerfCore::CEtwTraceGroup::ProcessEvents
2e diagperf!XPerfCore::CSession::ProcessEvents
2f diagperf!PerfDiagBoot::CTraceContext::Open
30 diagperf!BootScenario::PerformTroubleshooting
31 diagperf!BootScenario::TroubleShoot
32 diagperf!PerfDiagDm::CDmManager::HandleInstance
33 diagperf!WdiHandleInstance
34 wdi!WdipHandleInstance
35 wdi!WdipProcessDiagnosticMessage
36 wdi!WdipProcessSessionMessage
37 wdi!WdipSessionListener
38 ntdll!TppAlpcpExecuteCallback
39 ntdll!TppWorkerThread
3a KERNEL32!BaseThreadInitThunk
3b ntdll!RtlUserThreadStart</description>
		<content:encoded><![CDATA[<p>The stack trace from USB-keyboard generated dump on Windows 11 ARM64</p>
<p>MANUALLY_INITIATED_CRASH (e2)<br />
The user manually initiated this crash dump.<br />
Arguments:<br />
Arg1: 0000000000000000<br />
Arg2: 0000000000000000<br />
Arg3: 0000000000000000<br />
Arg4: 0000000000000000</p>
<p>0: kd> kc<br />
 # Call Site<br />
00 nt!KeBugCheck2<br />
01 nt!KeBugCheckEx<br />
02 kbdhid!KbdHidProcessCrashDump<br />
03 kbdhid!KbdHid_InsertCodesIntoQueue<br />
04 HIDPARSE!HidP_ModifierCode<br />
05 HIDPARSE!HidP_TranslateUsageAndPagesToI8042ScanCodes<br />
06 kbdhid!KbdHid_ReadComplete<br />
07 nt!IopUnloadSafeCompletion<br />
08 nt!IopfCompleteRequest<br />
09 HIDCLASS!HidpDistributeInterruptReport<br />
0a HIDCLASS!HidpInterruptReadComplete<br />
0b nt!IopfCompleteRequest<br />
0c Wdf01000!FxIrp::CompleteRequest<br />
0d Wdf01000!FxRequest::CompleteInternal<br />
0e Wdf01000!FxRequest::Complete<br />
0f Wdf01000!imp_WdfRequestComplete<br />
10 USBXHCI!Bulk_ProcessTransferEventWithED1<br />
11 USBXHCI!Bulk_EP_TransferEventHandler<br />
12 USBXHCI!Endpoint_TransferEventHandler<br />
13 USBXHCI!Interrupter_DeferredWorkProcessor<br />
14 Wdf01000!FxInterrupt::DpcHandler<br />
15 Wdf01000!FxInterrupt::_InterruptDpcThunk<br />
16 nt!KiExecuteAllDpcs<br />
17 nt!KiRetireDpcList<br />
18 nt!KxPlatformSwapStacksAndCall<br />
19 nt!KiPlatformSwapStacksAndCallReturn<br />
1a nt!KiDispatchInterrupt<br />
1b nt!HalpInterruptCheckForSoftwareInterrupt<br />
1c nt!KiInterruptException<br />
1d nt!KiUserInterruptHandler<br />
1e ntdll!RtlpHpTagFreeHeap<br />
1f ntdll!RtlFreeHeap<br />
20 msvcrt!free<br />
21 diagperf!XPerfCore::CPathNode::`scalar deleting destructor&#8217;<br />
22 diagperf!XPerfCore::CPathNode::Insert<br />
23 diagperf!XPerfCore::CPathNode::Insert<br />
24 diagperf!XPerfCore::CPathNode::Insert<br />
25 diagperf!XPerfCore::CPathNode::Insert<br />
26 diagperf!XPerfAddIn::CProcessInfoSource::ImageEvent<br />
27 diagperf!XPerfAddIn::CProcessInfoSource::OnEvent<br />
28 diagperf!XPerfCore::CSession::OnEventRecord<br />
29 diagperf!XPerfCore::CSession::EventRecordCallback<br />
2a diagperf!XPerfCore::CEtwTrace::EventRecordCallback<br />
2b sechost!EtwpProcessTraceLog<br />
2c sechost!ProcessTrace<br />
2d diagperf!XPerfCore::CEtwTraceGroup::ProcessEvents<br />
2e diagperf!XPerfCore::CSession::ProcessEvents<br />
2f diagperf!PerfDiagBoot::CTraceContext::Open<br />
30 diagperf!BootScenario::PerformTroubleshooting<br />
31 diagperf!BootScenario::TroubleShoot<br />
32 diagperf!PerfDiagDm::CDmManager::HandleInstance<br />
33 diagperf!WdiHandleInstance<br />
34 wdi!WdipHandleInstance<br />
35 wdi!WdipProcessDiagnosticMessage<br />
36 wdi!WdipProcessSessionMessage<br />
37 wdi!WdipSessionListener<br />
38 ntdll!TppAlpcpExecuteCallback<br />
39 ntdll!TppWorkerThread<br />
3a KERNEL32!BaseThreadInitThunk<br />
3b ntdll!RtlUserThreadStart</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Vostokov</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-767699</link>
		<dc:creator>Dmitry Vostokov</dc:creator>
		<pubDate>Mon, 27 Sep 2021 12:22:13 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-767699</guid>
		<description>Another method is to use Process Hacker (https://wj32.org/processhacker/) to terminate critical processes like csrss.exe:

0: kd&gt; .bugcheck
Bugcheck code 000000EF

0: kd&gt; kc
 # Call Site
00 nt!KeBugCheckEx
01 nt!PspCatchCriticalBreak
02 nt!PspTerminateAllThreads
03 nt!PspTerminateProcess
04 nt!NtTerminateProcess
05 nt!KiSystemServiceCopyEnd
06 nt!KiServiceLinkage
07 kprocesshacker
08 kprocesshacker
09 nt!IofCallDriver
0a nt!IopSynchronousServiceTail
0b nt!IopXxxControlFile
0c nt!NtDeviceIoControlFile
0d nt!KiSystemServiceCopyEnd
0e ntdll!NtDeviceIoControlFile</description>
		<content:encoded><![CDATA[<p>Another method is to use Process Hacker (https://wj32.org/processhacker/) to terminate critical processes like csrss.exe:</p>
<p>0: kd> .bugcheck<br />
Bugcheck code 000000EF</p>
<p>0: kd> kc<br />
 # Call Site<br />
00 nt!KeBugCheckEx<br />
01 nt!PspCatchCriticalBreak<br />
02 nt!PspTerminateAllThreads<br />
03 nt!PspTerminateProcess<br />
04 nt!NtTerminateProcess<br />
05 nt!KiSystemServiceCopyEnd<br />
06 nt!KiServiceLinkage<br />
07 kprocesshacker<br />
08 kprocesshacker<br />
09 nt!IofCallDriver<br />
0a nt!IopSynchronousServiceTail<br />
0b nt!IopXxxControlFile<br />
0c nt!NtDeviceIoControlFile<br />
0d nt!KiSystemServiceCopyEnd<br />
0e ntdll!NtDeviceIoControlFile</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Vostokov</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-741650</link>
		<dc:creator>Dmitry Vostokov</dc:creator>
		<pubDate>Sat, 02 Aug 2014 07:49:48 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-741650</guid>
		<description>Memory Dump API capability in Windows 8.1 
http://crashdmp.wordpress.com/2014/08/01/windows-8-1-update-live-dump-capability/
http://crashdmp.wordpress.com/2014/08/01/introducing-livedump-exe/</description>
		<content:encoded><![CDATA[<p>Memory Dump API capability in Windows 8.1<br />
<a href="http://crashdmp.wordpress.com/2014/08/01/windows-8-1-update-live-dump-capability/" rel="nofollow">http://crashdmp.wordpress.com/2014/08/01/windows-8-1-update-live-dump-capability/</a><br />
<a href="http://crashdmp.wordpress.com/2014/08/01/introducing-livedump-exe/" rel="nofollow">http://crashdmp.wordpress.com/2014/08/01/introducing-livedump-exe/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Vostokov</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-741637</link>
		<dc:creator>Dmitry Vostokov</dc:creator>
		<pubDate>Mon, 16 Sep 2013 12:01:26 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-741637</guid>
		<description>Another example of hardware manual dump is BugCheck 8E, {c0000005, ...

BUCKET_ID:  IP_MISALIGNED

&lt;p align="left"&gt;&lt;code&gt;0: kd&#62; .trap 0xffffffff99189ce4
ErrCode = 00000002
eax=00000115 ebx=8092596a ecx=00000000 edx=00cbff30 esi=00cbff38 edi=99189d64
eip=8092596c esp=99189d58 ebp=99189d64 iopl=0         nv up ei ng nz na pe cy
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010287
nt!NtUnmapViewOfSection+0x2:
8092596c 8c28            mov     word ptr [eax],gs    ds:0023:00000115=????????&lt;/code&gt;&lt;/p&gt;

&lt;p align="left"&gt;&lt;code&gt;0: kd&#62; u nt!NtUnmapViewOfSection
nt!NtUnmapViewOfSection:
8092596a e9cd8c2877      jmp     driverA+0x4263c (f7bae63c)
8092596f 51              push    ecx
80925970 64a124010000    mov     eax,dword ptr fs:[00000124h]
80925976 8a80d7000000    mov     al,byte ptr [eax+0D7h]
8092597c 3c01            cmp     al,1
8092597e 56              push    esi
8092597f 8b750c          mov     esi,dword ptr [ebp+0Ch]
80925982 8845fc          mov     byte ptr [ebp-4],al&lt;/code&gt;&lt;/p&gt;

The server was reported hang and all CPUs were busy.</description>
		<content:encoded><![CDATA[<p>Another example of hardware manual dump is BugCheck 8E, {c0000005, &#8230;</p>
<p>BUCKET_ID:  IP_MISALIGNED</p>
<p align="left"><code>0: kd&gt; .trap 0xffffffff99189ce4<br />
ErrCode = 00000002<br />
eax=00000115 ebx=8092596a ecx=00000000 edx=00cbff30 esi=00cbff38 edi=99189d64<br />
eip=8092596c esp=99189d58 ebp=99189d64 iopl=0         nv up ei ng nz na pe cy<br />
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010287<br />
nt!NtUnmapViewOfSection+0x2:<br />
8092596c 8c28            mov     word ptr [eax],gs    ds:0023:00000115=????????</code></p>
<p align="left"><code>0: kd&gt; u nt!NtUnmapViewOfSection<br />
nt!NtUnmapViewOfSection:<br />
8092596a e9cd8c2877      jmp     driverA+0x4263c (f7bae63c)<br />
8092596f 51              push    ecx<br />
80925970 64a124010000    mov     eax,dword ptr fs:[00000124h]<br />
80925976 8a80d7000000    mov     al,byte ptr [eax+0D7h]<br />
8092597c 3c01            cmp     al,1<br />
8092597e 56              push    esi<br />
8092597f 8b750c          mov     esi,dword ptr [ebp+0Ch]<br />
80925982 8845fc          mov     byte ptr [ebp-4],al</code></p>
<p>The server was reported hang and all CPUs were busy.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Vostokov</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-611526</link>
		<dc:creator>Dmitry Vostokov</dc:creator>
		<pubDate>Thu, 22 Nov 2012 12:32:29 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-611526</guid>
		<description>Memory dump from XenServer: 
http://support.citrix.com/article/CTX123177</description>
		<content:encoded><![CDATA[<p>Memory dump from XenServer:<br />
<a href="http://support.citrix.com/article/CTX123177" rel="nofollow">http://support.citrix.com/article/CTX123177</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Crash Dump Analysis &#187; Blog Archive &#187; Structural Memory Patterns (Part 1)</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-186346</link>
		<dc:creator>Crash Dump Analysis &#187; Blog Archive &#187; Structural Memory Patterns (Part 1)</dc:creator>
		<pubDate>Fri, 24 Sep 2010 10:58:18 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-186346</guid>
		<description>[...] Manual Dump (kernel) [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Manual Dump (kernel) [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Crash Dump Analysis &#187; Blog Archive &#187; Icons for Memory Dump Analysis Patterns (Part 66)</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-180612</link>
		<dc:creator>Crash Dump Analysis &#187; Blog Archive &#187; Icons for Memory Dump Analysis Patterns (Part 66)</dc:creator>
		<pubDate>Thu, 02 Sep 2010 16:13:12 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-180612</guid>
		<description>[...] Experts Magazine Online Today we introduce an icon for Manual Dump (kernel) [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Experts Magazine Online Today we introduce an icon for Manual Dump (kernel) [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Vostokov</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-164171</link>
		<dc:creator>Dmitry Vostokov</dc:creator>
		<pubDate>Wed, 07 Jul 2010 12:17:02 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-164171</guid>
		<description>We can also see code f001 on the following thread stack as well:

&lt;p align="left"&gt;&lt;code&gt;DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught.  This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 0000000000000091, A driver switched stacks using a method that is not supported by
	the operating system. The only supported way to extend a kernel
	mode stack is by using KeExpandKernelStackAndCallout.
Arg2: 0000000000000000
Arg3: fffff8000185bc40
Arg4: 0000000000000000&lt;/code&gt;&lt;/p&gt;

&lt;p align="left"&gt;&lt;code&gt;0: kd&gt; kL 100
Child-SP          RetAddr           Call Site
fffff880`0891f8c8 fffff800`01729c8a nt!KeBugCheckEx
fffff880`0891f8d0 fffff800`01700573 nt! ?? ::FNODOBFM::`string'+0x4904
fffff880`0891f910 fffff800`0170d8df nt!RtlDispatchException+0x33
fffff880`0891fff0 fffff800`016d2c42 nt!KiDispatchException+0x16f
fffff880`08920680 fffff800`016d17ba nt!KiExceptionDispatch+0xc2
fffff880`08920860 fffff800`016ca533 nt!KiPageFault+0x23a
fffff880`089209f8 fffff800`016a88c0 nt!memcpy+0x223
fffff880`08920a00 fffff800`016a8638 nt!KiOpFetchBytes+0x30
fffff880`08920a30 fffff800`0170dd6f nt!KiOpDecode+0x68
fffff880`08920a80 fffff800`0170d896 nt!KiPreprocessFault+0x53
fffff880`08920b10 fffff800`016d2c42 nt!KiDispatchException+0x126
fffff880`089211a0 fffff800`016d17ba nt!KiExceptionDispatch+0xc2
fffff880`08921380 00000000`0000f001 nt!KiPageFault+0x23a
fffff880`08921518 fffff800`016d9b4b 0xf001
fffff880`08921520 fffff800`016d94da nt!EnlightenedSwapContext_PatchXSave+0xa8
fffff880`08921560 fffff800`016da752 nt!KiSwapContext+0x7a
fffff880`089216a0 fffff800`016dc8af nt!KiCommitThreadWait+0x1d2
fffff880`08921730 fffff800`0169c1de nt!KeWaitForSingleObject+0x19f
fffff880`089217d0 fffff800`016db8bc nt!ExpWaitForResource+0xae
fffff880`08921840 fffff880`042fcd91 nt!ExAcquireResourceExclusiveLite+0x14f
[...]
fffff880`08921a10 fffff800`019eff16 nt!IopXxxControlFile+0x607
fffff880`08921b40 fffff800`016d2853 nt!NtDeviceIoControlFile+0x56
fffff880`08921bb0 00000000`7755ff2a nt!KiSystemServiceCopyEnd+0x13
00000000`0343f708 00000000`00000000 0x7755ff2a&lt;/code&gt;&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>We can also see code f001 on the following thread stack as well:</p>
<p align="left"><code>DRIVER_VERIFIER_DETECTED_VIOLATION (c4)<br />
A device driver attempting to corrupt the system has been caught.  This is<br />
because the driver was specified in the registry as being suspect (by the<br />
administrator) and the kernel has enabled substantial checking of this driver.<br />
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will<br />
be among the most commonly seen crashes.<br />
Arguments:<br />
Arg1: 0000000000000091, A driver switched stacks using a method that is not supported by<br />
	the operating system. The only supported way to extend a kernel<br />
	mode stack is by using KeExpandKernelStackAndCallout.<br />
Arg2: 0000000000000000<br />
Arg3: fffff8000185bc40<br />
Arg4: 0000000000000000</code></p>
<p align="left"><code>0: kd> kL 100<br />
Child-SP          RetAddr           Call Site<br />
fffff880`0891f8c8 fffff800`01729c8a nt!KeBugCheckEx<br />
fffff880`0891f8d0 fffff800`01700573 nt! ?? ::FNODOBFM::`string'+0x4904<br />
fffff880`0891f910 fffff800`0170d8df nt!RtlDispatchException+0x33<br />
fffff880`0891fff0 fffff800`016d2c42 nt!KiDispatchException+0x16f<br />
fffff880`08920680 fffff800`016d17ba nt!KiExceptionDispatch+0xc2<br />
fffff880`08920860 fffff800`016ca533 nt!KiPageFault+0x23a<br />
fffff880`089209f8 fffff800`016a88c0 nt!memcpy+0x223<br />
fffff880`08920a00 fffff800`016a8638 nt!KiOpFetchBytes+0x30<br />
fffff880`08920a30 fffff800`0170dd6f nt!KiOpDecode+0x68<br />
fffff880`08920a80 fffff800`0170d896 nt!KiPreprocessFault+0x53<br />
fffff880`08920b10 fffff800`016d2c42 nt!KiDispatchException+0x126<br />
fffff880`089211a0 fffff800`016d17ba nt!KiExceptionDispatch+0xc2<br />
fffff880`08921380 00000000`0000f001 nt!KiPageFault+0x23a<br />
fffff880`08921518 fffff800`016d9b4b 0xf001<br />
fffff880`08921520 fffff800`016d94da nt!EnlightenedSwapContext_PatchXSave+0xa8<br />
fffff880`08921560 fffff800`016da752 nt!KiSwapContext+0x7a<br />
fffff880`089216a0 fffff800`016dc8af nt!KiCommitThreadWait+0x1d2<br />
fffff880`08921730 fffff800`0169c1de nt!KeWaitForSingleObject+0x19f<br />
fffff880`089217d0 fffff800`016db8bc nt!ExpWaitForResource+0xae<br />
fffff880`08921840 fffff880`042fcd91 nt!ExAcquireResourceExclusiveLite+0x14f<br />
[...]<br />
fffff880`08921a10 fffff800`019eff16 nt!IopXxxControlFile+0x607<br />
fffff880`08921b40 fffff800`016d2853 nt!NtDeviceIoControlFile+0x56<br />
fffff880`08921bb0 00000000`7755ff2a nt!KiSystemServiceCopyEnd+0x13<br />
00000000`0343f708 00000000`00000000 0x7755ff2a</code></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Vostokov</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-158313</link>
		<dc:creator>Dmitry Vostokov</dc:creator>
		<pubDate>Mon, 14 Jun 2010 19:55:30 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-158313</guid>
		<description>Some virtualized environments may have their own methods to trigger a crash dump. For example, on XenServer we can see these bugchecks:

&lt;strong&gt;x86:&lt;/strong&gt;

&lt;p align="left"&gt;&lt;code&gt;BugCheck D1, {f001, 2, 0, f001}&lt;/code&gt;

&lt;p align="left"&gt;&lt;code&gt;DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000f001, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: 0000f001, address which referenced memory&lt;/code&gt;

&lt;p align="left"&gt;&lt;code&gt;STACK_TEXT:  
805573c0 0000f001 nt!KiTrap0E+0x238
80557430 ffdffc70 0xf001
80557450 804dcbef 0xffdffc70
80557454 00000000 nt!KiIdleLoop+0x10&lt;/code&gt;

&lt;strong&gt;x64:&lt;/strong&gt;

&lt;p align="left"&gt;&lt;code&gt;BugCheck 1E, {ffffffffc0000005, f001, 8, f001}&lt;/code&gt;

&lt;p align="left"&gt;&lt;code&gt;KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: 000000000000f001, The address that the exception occurred at
Arg3: 0000000000000008, Parameter 0 of the exception
Arg4: 000000000000f001, Parameter 1 of the exception&lt;/code&gt;

&lt;p align="left"&gt;&lt;code&gt;STACK_TEXT:  
fffff800`062b8358 fffff800`01896747 : nt!KeBugCheckEx
fffff800`062b8360 fffff800`018b1ce9 : nt! ?? ::FNODOBFM::`string'+0x250e7
fffff800`062b8960 fffff800`018b0ae5 : nt!KiExceptionDispatch+0xa9
fffff800`062b8b40 00000000`0000f0: nt!KiPageFault+0x1e5
fffff800`062b8cd8 fffffa60`02a7e685 : 0xf001
fffff800`062b8ce0 fffff800`018b6583 : intelppm!C1Idle+0x9
fffff800`062b8d10 fffff800`018b62a1 : nt!PoIdle+0x183
fffff800`062b8d80 fffff800`01a88860 : nt!KiIdleLoop+0x21
fffff800`062b8db0 00000000`fffff800 : nt!zzz_AsmCodeRange_End+0x4
fffff800`062b20b0 00000000`00000000 : 0xfffff800&lt;/code&gt;</description>
		<content:encoded><![CDATA[<p>Some virtualized environments may have their own methods to trigger a crash dump. For example, on XenServer we can see these bugchecks:</p>
<p><strong>x86:</strong></p>
<p align="left"><code>BugCheck D1, {f001, 2, 0, f001}</code></p>
<p align="left"><code>DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)<br />
An attempt was made to access a pageable (or completely invalid) address at an<br />
interrupt request level (IRQL) that is too high.  This is usually<br />
caused by drivers using improper addresses.<br />
If kernel debugger is available get stack backtrace.<br />
Arguments:<br />
Arg1: 0000f001, memory referenced<br />
Arg2: 00000002, IRQL<br />
Arg3: 00000000, value 0 = read operation, 1 = write operation<br />
Arg4: 0000f001, address which referenced memory</code></p>
<p align="left"><code>STACK_TEXT:<br />
805573c0 0000f001 nt!KiTrap0E+0x238<br />
80557430 ffdffc70 0xf001<br />
80557450 804dcbef 0xffdffc70<br />
80557454 00000000 nt!KiIdleLoop+0x10</code></p>
<p><strong>x64:</strong></p>
<p align="left"><code>BugCheck 1E, {ffffffffc0000005, f001, 8, f001}</code></p>
<p align="left"><code>KMODE_EXCEPTION_NOT_HANDLED (1e)<br />
This is a very common bugcheck.  Usually the exception address pinpoints<br />
the driver/function that caused the problem.  Always note this address<br />
as well as the link date of the driver/image that contains this address.<br />
Arguments:<br />
Arg1: ffffffffc0000005, The exception code that was not handled<br />
Arg2: 000000000000f001, The address that the exception occurred at<br />
Arg3: 0000000000000008, Parameter 0 of the exception<br />
Arg4: 000000000000f001, Parameter 1 of the exception</code></p>
<p align="left"><code>STACK_TEXT:<br />
fffff800`062b8358 fffff800`01896747 : nt!KeBugCheckEx<br />
fffff800`062b8360 fffff800`018b1ce9 : nt! ?? ::FNODOBFM::`string'+0x250e7<br />
fffff800`062b8960 fffff800`018b0ae5 : nt!KiExceptionDispatch+0xa9<br />
fffff800`062b8b40 00000000`0000f0: nt!KiPageFault+0x1e5<br />
fffff800`062b8cd8 fffffa60`02a7e685 : 0xf001<br />
fffff800`062b8ce0 fffff800`018b6583 : intelppm!C1Idle+0x9<br />
fffff800`062b8d10 fffff800`018b62a1 : nt!PoIdle+0x183<br />
fffff800`062b8d80 fffff800`01a88860 : nt!KiIdleLoop+0x21<br />
fffff800`062b8db0 00000000`fffff800 : nt!zzz_AsmCodeRange_End+0x4<br />
fffff800`062b20b0 00000000`00000000 : 0xfffff800</code></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dmitry Vostokov</title>
		<link>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-83948</link>
		<dc:creator>Dmitry Vostokov</dc:creator>
		<pubDate>Fri, 10 Jul 2009 17:44:39 +0000</pubDate>
		<guid>https://www.dumpanalysis.org/blog/index.php/2007/12/12/crash-dump-analysis-patterns-part-41a/#comment-83948</guid>
		<description>If you see myfault on the stack then the dump was generated by NotMyFault sysinternals tool. I have started to see this from x64 dumps

&lt;p align="left"&gt;1: kd&gt; k
Child-SP          RetAddr           Call Site
fffffa60`06bf7558 fffff800`0165712e nt!KeBugCheckEx
fffffa60`06bf7560 fffff800`0165600b nt!KiBugCheckDispatch+0x6e
fffffa60`06bf76a0 fffffa60`053da17a nt!KiPageFault+0x20b
fffffa60`06bf7830 fffffa60`053da397 myfault+0x117a
fffffa60`06bf7990 fffff800`018dd25a myfault+0x1397
fffffa60`06bf79f0 fffff800`018f5f76 nt!IopXxxControlFile+0x5da
fffffa60`06bf7b40 fffff800`01656e33 nt!NtDeviceIoControlFile+0x56
fffffa60`06bf7bb0 00000000`77525aea nt!KiSystemServiceCopyEnd+0x13&lt;/p&gt;</description>
		<content:encoded><![CDATA[<p>If you see myfault on the stack then the dump was generated by NotMyFault sysinternals tool. I have started to see this from x64 dumps</p>
<p align="left">1: kd> k<br />
Child-SP          RetAddr           Call Site<br />
fffffa60`06bf7558 fffff800`0165712e nt!KeBugCheckEx<br />
fffffa60`06bf7560 fffff800`0165600b nt!KiBugCheckDispatch+0&#215;6e<br />
fffffa60`06bf76a0 fffffa60`053da17a nt!KiPageFault+0&#215;20b<br />
fffffa60`06bf7830 fffffa60`053da397 myfault+0&#215;117a<br />
fffffa60`06bf7990 fffff800`018dd25a myfault+0&#215;1397<br />
fffffa60`06bf79f0 fffff800`018f5f76 nt!IopXxxControlFile+0&#215;5da<br />
fffffa60`06bf7b40 fffff800`01656e33 nt!NtDeviceIoControlFile+0&#215;56<br />
fffffa60`06bf7bb0 00000000`77525aea nt!KiSystemServiceCopyEnd+0&#215;13</p>
]]></content:encoded>
	</item>
</channel>
</rss>
