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
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:
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)
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Google it up: http://lmgtfy.com/?q=e1q62x64
Update your Intel Nic Drivers