Where did the crash dump come from?
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
This is the basic check and very useful if your customer complains that the fix you sent yesterday doesn’t work. Check the computer name from the dump. It could be the case that your fix wasn’t applied to all computers. Here is a short summary for different dump types:
1. Complete/kernel memory dumps: dS srv!srvcomputername
1: kd> dS srv!srvcomputername
e17c9078 "COMPUTER-NAME"
2. User dumps: !peb and the subsequent search inside the environment variables
0:000> !peb
PEB at 7ffde000
...
...
...
Environment: 0x10000
...
0:000> s-su 0x10000 0x20000
...
...
000123b2 "COMPUTERNAME=COMPUTER-NAME"
...
...
dS command shown above interpret the address as a pointer to UNICODE_STRING structure widely used inside the Windows kernel space
1: kd> dt _UNICODE_STRING
+0x000 Length : Uint2B
+0x002 MaximumLength : Uint2B
+0x004 Buffer : Ptr32 Uint2B
DDK definition:
typedef struct _UNICODE_STRING {
USHORT Length;
USHORT MaximumLength;
PWSTR Buffer;
} UNICODE_STRING *PUNICODE_STRING;
Let’s dd the name:
1: kd> dd srv!srvcomputername l2
f5e8d1a0 0022001a e17c9078
Such combination of short integers following by an address is usually an indication that you have a UNICODE_STRING structure:
1: kd> du e17c9078
e17c9078 "COMPUTER-NAME "
We can double-check it with dt command:
1: kd> dt _UNICODE_STRING f5e8d1a0
"COMPUTER-NAME"
+0x000 Length : 0x1a
+0x002 MaximumLength : 0x22
+0x004 Buffer : 0xe17c9078 "COMPUTER-NAME"
- Dmitry Vostokov -
_1125.png)
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:
August 4th, 2008 at 9:31 pm
[…] Where did the crash dump come from? […]
January 8th, 2009 at 4:34 pm
[…] (0×7D9) - The Year of DebuggingPart 1 focused on using a debugger to extract a computer name from memory dumps. Here is a very simple […]
August 19th, 2009 at 11:05 pm
Alex Ionescu in his comment advised to use !ustr instead of dt _UNICODE_STRING:
http://www.softwaregeneralist.com/2009/08/17/reading-notebook-17-august-09/#comments
March 11th, 2010 at 11:15 am
On x64 we should use dq command instead of dd. Or better use dp command that takes into account platform pointer size