Crash Dump Analysis Patterns (Part 52)
Sometimes processes dump themselves using Microsoft DbgHelp API when they encounter internal errors or for other debugging purposes. I separate this from unhandled exceptions which usually cause an external postmortem debugger process to dump memory contents as explained in my previous posts:
It is important to understand that a process can dump itself for any reasons that came to mind of an application designer and not only as a reaction to hardware and software exceptions. In any case it is useful to look at raw stack dump of all threads and search for first chance exceptions like c0000005 and custom exception handlers.
I call this pattern Self-Dump and consider it as a specialized version of Special Stack Trace pattern. The typical thread stack might look like (and might be Incorrect Stack Trace that requires manual reconstruction):
0:012> kL
ChildEBP RetAddr
0151f0c4 77e61f0c ntdll!KiFastSystemCallRet
0151f0d4 08000000 kernel32!CreateFileMappingW+0xc8
WARNING: Frame IP not in any known module. Following frames may be wrong.
0151f0f0 7c82728b 0x8000000
0151f0f4 77e63e41 ntdll!NtMapViewOfSection+0xc
0151f12c 77e6440c kernel32!MapViewOfFileEx+0x71
0151f14c 7c826d2b kernel32!MapViewOfFile+0x1b
0151f1d4 028ca67c ntdll!ZwClose+0xc
0151f2a4 028cc2f1 dbghelp!GenGetClrMemory+0xec
0151f2b4 028c8e55 dbghelp!Win32LiveSystemProvider::CloseMapping+0×11
0151f414 00000000 dbghelp!GenAllocateModuleObject+0×3c5
Raw stack data should reveal DbgHelp API calls:
0151f944 00000000
0151f948 00000000
0151f94c 0151f9c0
0151f950 028c7662 dbghelp!MiniDumpWriteDump+0×1b2
0151f954 ffffffff
0151f958 00000cb0
0151f95c 00c21ea8
0151f960 00c21f88
0151f964 00c21e90
0151f968 00c21fa0
0151f96c 00000002
0151f970 00000000
0151f974 00000000
0151f978 00000000
0151f97c 7c829f60 ntdll!CheckHeapFillPattern+0×64
0151f980 ffffffff
0151f984 7c829f59 ntdll!RtlFreeHeap+0×70f
0151f988 7c34218a msvcr71!free+0xc3
0151f98c 00000000
0151f990 00000000
0151f994 00c21e90
0151f998 00c21fa0
0151f99c 00c21ea8
0151f9a0 00c21f88
0151f9a4 00000002
0151f9a8 021a00da
0151f9ac 001875d8
0151f9b0 7c3416db msvcr71!_nh_malloc+0×10
0151f9b4 0151f998
0151f9b8 001875d8
0151f9bc 00000000
0151f9c0 0151fbe4
0151f9c4 57b77d01 application!write_problem_report+0×18d1
0151f9c8 ffffffff
0151f9cc 00000cb0
0151f9d0 00000718
0151f9d4 00000002
0151f9d8 00000000
0151f9dc 00000000
0151f9e0 00000000
0151f9e4 00029722
0151f9e8 0151fc20
Partially reconstructed stack trace might look like:
0:012> k L=0151f94c
ChildEBP RetAddr
0151f0c4 77e61f0c ntdll!KiFastSystemCallRet
0151f94c 028c7662 kernel32!CreateFileMappingW+0xc8
0151f9c0 57b77d01 dbghelp!MiniDumpWriteDump+0×1b2
0151fbe4 57b77056 application!write_problem_report+0×18d1
0151fc30 579c83af application!TerminateThread+0×18
- Dmitry Vostokov @ DumpAnalysis.org -
April 3rd, 2009 at 5:55 pm
[…] message box parameters we see a self-diagnostic […]
July 14th, 2009 at 6:21 pm
[…] we have an instance of Self-Dump pattern here. In case of custom unhandled exception filters not resorting to WER faulrep.dll […]
September 24th, 2010 at 10:57 am
[…] Self-Dump […]
August 10th, 2015 at 7:31 pm
Sometimes, such truncated stack traces hide Self-Dump processing:
4 Id: 10e4.2838 Suspend: 0 Teb: 7efa6000 Unfrozen
ChildEBP RetAddr
026beb1c 00000000 ntdll!NtGetContextThread+0×12
We need to examine raw stack Execution Residue to see the presence of DbgHelp API.