Quick Overview on how to look at .dmp files from BSOD crashes

[Cerathalis]

This is from another thread, figured I would put it out here for anyone to check out.

Ok a supper quick Crash dump analysis guide: (If the above suggestions don't work)

MiniDumps : Suck for everything but the bugcheck code
Kernel Dumps: Good for drivers and crashes like that
Full Dumps: They have all your user memory space also, useful for hangs / leaks / etc

You may have to google on setting your machine up to collect the dump properly or you can end up with truncated memory dumps etc.

Download WinDBG from MS

File -> Symbol File Path
Enter: SRV*c:\example_symbol_storage_folder*http://http://msdl.microsoft.com/download/symbols;

Repeat that for any other symbol download locations you have, but this will get you MS's publicly scrubbed symbols.

File -> Open Crash Dump | Select your .dmp file

To log what your doing to a file do: .logopen "c:\Example_Dump_Analysis\DebugSession.log"
When your at the end of your commands close the log file for reading: .logclose
The log is really nice for !process 0 7 and other commands that can over run the display buffer and it makes a nice txt file you can copy out into forums etc.

Once it loads and debugger connects type: .reload /f;!analyze -v;!vm

That will force symbol reload and can help resolve symbol issues sometimes, !analyze -v does the MS automated analysis gives you the crashing call stack etc and tries to pin the blame on something (Watch out sometimes it will just pick the last NON Microsoft item in the stack , !vm displays the system memory use easy way to tell if you ran out of paged or non paged pool memory etc and show whats running.

For hangs use !analyze -v -hang (This will try to find the hang and tell you) if that doesn't work !locks -v (For system locks its usually an exclusively owned lock with threads waiting normally system threads etc)

For high CPU in a Kernel / System dump:
!process 0 7 (displays all processes) Look for high kernel / user time - that's the guy who's eating CPU and you can see what the thread is doing via the call stack hopefully.

For Process dumps like DrWatson / Procdump:
!runaway

--

Ok, pick calls out of the call stack like NTKernel!SomeStupidCrashingCall and google them, sometimes it can help narrow down finding others who have had the problem. Remember !analyze -v is an automated process and not always correct but its a nice start.
kv - display stack
!thread - display current thread, usually the crashing one
F1 for the help file - read learn memory http://www.dumpanalysis.org/ also an awesome site, the guy is pretty much the GOD of debugging.

I hope I didn't typo any of the commands and I hope it helps.

Example of looking at a call stack:

STACK_TEXT: (This is the call stack of the crashing process as displayed by !analyze -v)
fffff880`06777698 fffff800`02c79ca9 : 00000000`0000000a 00000000`000000a0 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`067776a0 fffff800`02c78920 : fffffa80`06a39970 00000000`00000000 00000000`00000001 00000000`00000001 : nt!KiBugCheckDispatch+0x69
fffff880`067777e0 fffff880`019c0867 : fffffa80`081adc30 fffffa80`085a8000 00000000`00000000 00000000`00000000 : nt!KiPageFault+0x260 This is the start of the crash dump process so you can ignore it for the most part the fault has happened before this point
fffff880`06777970 fffffa80`081adc30 : fffffa80`085a8000 00000000`00000000 00000000`00000000 00000000`00000000 : e1q62x64+0x1b867 Last Non Microsoft Driver, always worth checking out
fffff880`06777978 fffffa80`085a8000 : 00000000`00000000 00000000`00000000 00000000`00000000 fffff880`019c8ad5 : 0xfffffa80`081adc30
fffff880`06777980 00000000`00000000 : 00000000`00000000 00000000`00000000 fffff880`019c8ad5 fffffa80`00000000 : 0xfffffa80`085a8000

Display the info on that driver
4: kd> lmvm e1q62x64
start end module name
fffff880`019a5000 fffff880`019f1000 e1q62x64 T (no symbols)
Loaded symbol image file: e1q62x64.sys
Image path: \SystemRoot\system32\DRIVERS\e1q62x64.sys
Image name: e1q62x64.sys
Timestamp: Thu Jul 08 15:07:00 2010 (4C364C04)
CheckSum: 000506D5
ImageSize: 0004C000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

Google it up: http://lmgtfy.com/?q=e1q62x64
Update your Intel Nic Drivers

[ottoyu34]

Great post, this is very useful. Thank you.

[Cerathalis]

Yea it took a while for me to start bumbling my way through dmp files, I'm still pretty much as a "monkey see monkey do" level on a lot of things. But it can really narrow down what your looking for quickly sometimes, other times you will suffer blunt force trauma from walls of seemingly meaningless text.

Ohh and since this is an OC'ers board watch out for memory corruption based issues. If your repeatedly Blue Screening and the Stop Codes or call stack is pointing to different somewhat random drivers. You are probably just pushing the RAM too much or a driver is acting out really badly. These are the harder issues to track down, I would suggest the simple brute force method "start->run "msconfig"" remove the non MS junk from your start up then run a stress tester or something to reproduce if it does it chances are its not a driver. If its stable enable 1 at a time in msconfig until you find the source.

But if you really want to jump into the deep end, check your windbg help file on the following commands.
uf

//This disables the area around the call into assembly you can trace back what happened checking the registers etc.
dds esp //This is basically a display of the systems call stack, useful for framing a corrupted call stack. Can also give an idea of what the system is doing.
dds //Use this after the esp to keep walking down the stack.

Other then that search around for instructions on using "verifier" and special pool etc for tracking down memory corruption issues. Watch out, verifier has settings that will cause a BSOD fault on some actions that would not crash the system.

[xeromist]

Interesting, thanks for the info dude!