I'm not talking about the NT Debugging blog. This is one of my personal experiences with NT debugging.
A couple weeks ago, I was looking at a Windows VM that was apparently crashing on a somewhat regular basis. Through the use of usual logfile analysis techniques we can get some correlations and some probable causes. In this particular case it was plainly evident that the system was working perfectly until some 3rd party software was loaded. Then the regular unexpected shutdowns began, about once every day or two.
The correlation was found through the use of the Reliability and Performance Monitor, which is a very nifty tool:
A "stop," or "bugcheck" we are all familiar with. It produces a memory dump file in %SystemRoot%\MEMORY.DMP and other "minidumps" in %SystemRoot%\Minidump\ unless otherwise configured. It's pretty much, well, a dump of everything that the system had in memory when the offense took place.
But do we really know what to do with an NT memory dump? I have to say I didn't really, and I was a little embarrassed about it. So I set out to figure out what useful information I could really glean from that memory dump. Having that extra bit of tenacity to really dig down deep and identify with greater precision what the root of the problem is, rather than just saying "well it's some sort of software compatibility problem, better reformat the hard drive!" can help you out in your quest to be the office guru.
Well it turns out there's a nice utility called Windbg.exe. You can get it from the Windows SDK. To effectively debug an application, you need debugging symbols. Fortunately, Microsoft has provided some public debugging symbols on their own symbol server. I hear that Microsoft also has a private symbol tree for internal use only, but we'll just have to settle for the public ones.
Here's a KB that will help you get Windbg and your symbols path set up correctly.
Now that you have that configured, simply drag the memory dump file into the Windbg window, and it will tell you with much greater certainty exactly what driver and/or interaction caused the BSOD.
One of the interesting things that Windbg can reveal, is that sometimes drivers installed by crashy software still get loaded even after the software has been uninstalled. And if all that machine code-looking stuff seems scary, Windbg also outputs the simple line: "Probably caused by: driver.sys" that can at least give you a lead.
There are also other dump file analyizers, such as WhoCrashed, that may be more to your liking.
And lastly, be careful about sharing your memory dumps, as they might contain password hashes.