Crash Dump Analysis Patterns (Part 52)

CARE: Crash Analysis Report Environment

DATA (Dump Analysis + Trace Analysis) Facebook group
Please join the community of memory (dump) and trace analysis engineers. This group promotes scientific methods and memory dump-based worldview.

Twitter @ DumpAnalysis
You can now follow portal and blog news at DumpAnalysis on Twitter

LinkedIn Group Dr. Watson Enthusiasts
All about Dr. Watson errors and more. Get news, excerpts and progress reports about the forthcoming book The Science of Dr. Watson: An Illustrated History of Debugging (ISBN 978-1906717070)

2010 (0x7DA) - The Year of Dump Analysis
2011 (0x7DB) - 2020 (0x7E4) The Debugging Decade

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 -

           

Announcements

Coming Soon:

Debugging Notebook: Essential Concepts, WinDbg Commands and Tools

Crash Dump Analysis for System Administrators and Support Engineers

New Magazines:

Debugged! MZ/PE: MagaZine for/from Practicing Engineers


New Books:

Memory Dump Analysis Anthology, Volume 3

First Fault Software Problem Solving: A Guide for Engineers, Managers and Users

x64 Windows Debugging: Practical Foundations

Also available:

Windows Debugging: Practical Foundations

DLL List Landscape: The Art from Computer Memory Space

Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov

WinDbg: A Reference Poster and Learning Cards

Memory Dump Analysis Anthology, Volume 2

Memory Dump Analysis Anthology, Volume 1

New Children's Book:

Baby Turing

2 Responses to “Crash Dump Analysis Patterns (Part 52)”

  1. Crash Dump Analysis » Blog Archive » Blocked threads, message box and self-diagnosis: pattern cooperation Says:

    […] message box parameters we see a self-diagnostic […]

  2. Crash Dump Analysis » Blog Archive » On Self Dumps of Secure String API Says:

    […] we have an instance of Self-Dump pattern here. In case of custom unhandled exception filters not resorting to WER faulrep.dll […]

Leave a Reply