Great TechEd video by Mark Russinovich from Sysinternals on doing
crash dump analysis. Some brief reminder notes for myself:
- Turn on Kernel dump (can be about ~70MB), not the small dump (too small), not the whole memory dump, way way too big (includes user mode stuffs though -- so, maybe, if you're desperate, and can afford the disk space).
- WinDbg (download Debugging Tools for Windows)
File | Symbol File Path...
srv*c:\symbols*http://msdl.microsoft.com/download/symbols
(File | Save Workspace to retain this setting)
- Running verifier.exe
- “Select individual settings” -- choose everything bit “Low resources simulation”
- Select drivers
First try suspicious drivers. Then you can try all unsigned drivers. Then try all drivers in groups of 10-20.
Because ... Special Pool setting, does the memory checkerboard bit, but only if it can afford the resources. Turning on special pool for too many drivers releases the ‘invalid’ checkboard squares back to valid memory and defeats the whole thing.
Also, run the Windows Memory Diagnostic at any point if you suspect memory problems.
Installs to boot floppy...
If ‘memory_corruption’ is to blame, then it's not even picking a driver to blame, just saying, hey, memory_corruption.
If you're still stuck, some misc tricks:
!vm Make sure memory pools are not full - could be memory leak. (if full, use !poolused (requires pool tagging to be on))
Examine current thread with !thread (may or may not be related)
List all processes: !process 0 0
If verifier detected deadlock: !deadlock
!help for additional commands
Stack Trashing can be nasty, makes stack really hard to analyze.
After that, you can do certain debugging things that then start requiring a second machine to remote debug, yada yada.
Check out ADPlus.vbs in the Debugging download hoo-ha - good stuffs to help record dumps of crashing apps.
Remember the default frame count for ‘k’ and its related commands is 20 -- if you need more than that, you have to specify the frame count in the command - like ‘k 100’
Good MSDN Article Overview
this page mentions:
!analyze -hang -v
Then I always double check with !locks command because there could be multiple hang conditions in a dump.
The same parameter can be used in kernel memory dumps too. But double checking ERESOURCE locks (!locks), kernel threads (!stacks) and DPC queues (!dpcs) manually is highly recommended.
- Dmitry Vostokov -
keywords: bsod, blue screen of death
tags:
ComputersAndTechnology