BSOD debugging basics guide

[qwertylesh]

Crash debugging for Windows NT or above
A starters guide to learn how-to debug a minidump file from a Blue Screen Of Death

Part 1, Setting up your Debugging Tools
In this part, you'll learn how to setup a free debugging tool to help diagnose a Windows 'blue screen of death' and how to use an automatic method for the symbol and file version process.

1) The Windows Debugging Tools
Download the Windows Debuging Tools

2) Getting the Symbol files
Once the Debugging Tools are Downloaded and Installed, you need to setup your symbol file retrieval.
Click Start, All Programs/Programs, Debugging Tools. Run WinDBG.


On the Debugger Menubar, Click File then Symbol Path.


In the Symbol Search Path dialog enter:

SRV*C:\custompath*http://msdl.microsoft.com/download/symbols

You may name 'custompath' anything you wish, I recommend a folder name without spaces.
You can optionally download whole symbol file sets off the Microsoft website although they are typically 600-800MB in size, the URL method instructed above is a much more efficient method as it only downloads the symbols necessary for the debugging (approximately 2-15mb)

3) Image File Paths
This step is for if the PC's OS has been updated since the crash dump file was written, or if your unsure the file versions aren't still the same, if these conditions don't apply, you may skip this step.
On the Debugger Menubar; Click File then Image File Path


In the Image Search Path dialog enter:

C:\Windows\System32; http://www.alexander.com/SymServe

Remember, For basic crash debugging, the Step 3 is a requirement if the file versions have changed or else an accurate result wont be achievable!

!!! An Internet connection is required to continue !!!

Once you've completed the 3 steps above, goto Menubar: File click Open Crash Dump.
Navigate your way to C:\Windows\Minidump and select oldest (View the file list by details and choose the Date Modified column and sort by Ascending) .DMP file available

Part 2, Crash debugging and Analysis
In this part, you'll learn how to use the debugging tools key commands to learn more about why the OS crashed.
Once you've opened a Crash Dump file the debugger will retrieve relevant symbols and file versions automatically, the debugger will then debug the dump file.

Tips:
A common problem that beginning debuggers encounter is where the symbols path is not configured correctly resulting in asterisked ASCII boxes notifying you that your debug tool cannot find the symbols, in this situation the probable cause by the debug analysis isn't accurate.
To prevent file download corruption it is strongly recommended that you have checked your RAM for Errors/Incompatibility before debugging with this method. (as ram problems will corrupt downloads, including the debug symbols.)

1) Analyzing the crash.
At the bottom of the screen there will be a line for text input, lets call this the console.

Type into the console !Analyze -v then press Enter

Don't panic or repeat the command if it seems like nothings happening, the debug result time will vary by certain factors; your Internet connection speed, crash dump size (mini, kernel only or full memory), system specifications, and file-system condition
In time results will enumerate so please be patient, the extra time the debugger takes to open the crash file is actually a good indication that your tools are configured correctly, If the file opened instantly, you should review the displayed information to ensure your debugging tools are configured properly.

You should now have a probable cause given by the analysis of the debugger, this cause is likely to indicate if the BSOD was caused due specifically by a driver or by hardware factors affecting kernel memory.
Other areas of the Analysis to take note of is the image_name and module_name entry under the debugging details, these fields will indicate a specific file if your BSOD is driver related.

2) Additional File Analysis (LMV):
The LMV command allows you to quickly obtain detailed file information from within the debugger. The LMV command will give you an indication of what the file does or whom the vendor of the file is, this information gives you an avenue for, updating, repair or further investigation.
After the debug analysis is performed, In the console use the LMV command to learn more about the faulting file (module_name or image_name)

Remember, If your minidump folder is not saving your crash-dumps, check your settings: Win+Pause, Advanced, in Start up and Recovery click the Settings button, under the Write debugging information field, choose kernel memory dump.

If you found this guide to be helpful, checkout the original article below,
Article (2005) How to solve Windows system crashes in minutes Credits: Dirk A. D. Smith from Alexander.com & Network World.
Although written by memory through my POV, information herein this guide originated from Network World, therefore the above guidelines, url's, information and debugging method may be subject to copyright, please don't add this guide to the wiki.

Useful debugging resources:
Windows crash debugging @ thomaskoetzing.de - Handy knowledge base section amongst other usefull debugging information
Analyzing Windows Crash Dump Files - A more comprehensive guide to debugging
blue screen of death survival guide - handy list of common BSOD causes.

[The Mafia]

Brilliant article.

I wish this was available a few months back when I had to learn how to diagnose crash dumps.

The third part is something new to me thought.

Well done mate.

[qwertylesh]

Thanks for the kind words

This is my favorite method for debugging, No worrying about symbols or file versions, which means you can get around to figuring out a BSOD even if the end user has ran updates.
I wasn't actually aware of how many guides were out there for basic crash debugging until after I wrote up this one, I had only found the source article beforehand, seems theres allot of them though (when you know what to look for ), some interesting links under usefull resources makes for a good read too.

Hopefully this guide will help some people out who have gotten buggy drivers/files

[danstis]

Ahh good post...

This is a method that I have used for quite a while, gets results more often then not.

Thanks for sharing the info with the community!

[qwertylesh]

TBQH, I selfishly posted it here because I'm on the forums so frequently
Thanks danstis, I'm glad it can help people out who get software bsods and are unsure of what to do to fix them.

[alch]

Ill send you the dump and you can analyze it for me?

[qwertylesh]

its best if you do it, if i analyze it I would need the same operating system and even then my debugger would likely just guess the problem is related to a driver loaded on your system and missing on mine (since our hardware would be different, so drivers would likely come from different vendors also being different versions) if your system is stable enough for you to do it (i like to suggest turning off all start processes and non Microsoft services to get a bit of reliability back when your debugging on a bad system) you'll get far more accurate results compared to getting someone else to do it, unless they're really good or spend a lot of time setting up a system similar to yours.
This guide is helpfull especially if you have a bsod problem with say full screen games but out of game is stable, or if its related to driver signature enforcment, things like that, where you can use the system enough to determine if its a file or software problem.

[KatatonicKwan]

Besides the ultimate boot disk - What tools do you recommend I can put on a USB for installing programs and debugging server environments?

[qwertylesh]

I haven't got anything specific in mind, but I think live kernel debugging is something you should look into learning if you don't do it already, that way you can debug systems over serial (RS232) while the systems still in its kernel panic state "BSOD'ed". I'd say not really a bootable USB drive but a notebook and patch serial cable would be tools thatd help in the environment your asking about.

If your after handy usb bootable utilities, then Barts PE builder is very handy. You don't need a Vista licence and you can with that setup a preinstall Vista or XP if you want to a usb drive for easy system access.
I have Lsoft Active @Boot Disk working on a usb drive, I find this one of the most useful things to have handy, It runs a cut down vista kernel with a very simple but well done shell. I used the HP format tool to make the USB's partition set to active, then I used VistaBoot Pro to write a Vista BCD to the drive, then extracted the Active Boot disk ISO onto it, works a charm and gives you lots of tools to fix and troubleshoot systems (especially data recovery related).
If I find a good bootable environment for debugging on, I'll post about it in this thread, but for now I don't use them for debugging crashes because I'm not aware of any which are good for crash debugging on.

[KatatonicKwan]

Cheers for that.

I'll be getting a nice 10" laptop and will begin setting up a nice portable work station

[adambug]

Hi are the instructions still valid? As it wont download the symbols for myself.

The following path doesnt seem to work anymore -
http://msdl.microsoft.com/download/symbols

[qwertylesh]

if you tried the method exactly as posted and it has not retrieved symbols, it could be some program similar to or a firewall thats stopping it. If that isnt the cause of the problem, maybe something on microsofts end, afaik they should still be offering the symbols, as long as your using the latest debugging tool version for your operating system it should work.

[Spork!]

I wish I could get a bsod... this black on black blankness is strating to shit me.
Will have some time to troubleshoot tomorrow, hopefully by tomorrow night I will be up and running again, or at least know what the problem is.
Once I am, I'm sure this guide will be a great help in achieving 4GHz+ stable, it should take the guesswork out of "why did that just crash"...

[qwertylesh]

Yeah i found debuggings handy for that recently too.

I took an OC off a system and checked all its crash dumps, a few said in bad/unstable cpu and some said bad/unstable ram, so i knew the oc as no good, parts were still fine after 24 hours of prime blending and 10 hours of linpack all the residual norm values were exact so i was happy with knowing what was going on.
It wasn't my system, I advised the owner to keep the dram freq at stock when upping the cpu speeds and its now oc'd stable.
(happens with cheapy value ram, you know.)

[core69]

I tried following the steps but i can't find the minidump?? there's no minidump file in my system root dir.

any help much appreciated

cheers