In Part 1 we've seen what can cause a BSOD and what information we can collect after it happens, so we could investigate the problem.
Well, Microsoft gives us the Debugging Tools for Windows toolkit.
Go to the link, and download the latest version that is appropriate to your system (i.e. x86/64bit).
This toolkit allows us to diagnose the memory dump files that Windows saved during the BSOD and hopefully pinpoint the root cause of the problem.
While debugging the dump files, the tools compare the drivers' and operating files' information from the memory collected in the dump file, to a database of "symbols" from Microsoft. the Symbols database will most likely be used from the internet using Microsoft Symbols server, but can also be downloaded and used offline (it's a huge file- only download if you must...).
- At first we run the WinDbg utility from the Debugging Tools for Windows we just installed.
- In the File menu - "Open Crash Dump" - Choose you Minidump or Memory.dmp file.
- Let the debugger do its work...
what we're interested to find are (you're welcome to use the "Find" function from the Edit menu):
- BugCheck = equals to the BSOD error code. In case we didn't see the error message and still don't know which error we got.
- "Probably caused by" = this line is followed by the debugger suggestion of what caused the BSOD that happened while this dump file was created.
Examples from my experience:
"SYMEVENT.SYS" > damn Norton AV... (suggestion: uninstall and replace with NOD32 :))
"nv4_disp.sys" or "nv4_mini.sys" > Nvidia Drivers (suggestion: update drivers)
"memory_corruption" > bad RAM maybe? (suggestion: run Windows Memory Diagnostics)
But I strongly believe in understanding the problem and not just fixing or bypassing it. That way you can be sure you won't get the same error again the next day..
I hope you will find this information useful.
