How to figure out why your computer just suffered a Blue Screen of Death

Oh no! You’ve gotten that blasted Blue Screen of Death and now you want to figure out what the heck caused your obstinate computer to crash?

Most people never take the time to obviate the problem either because they lack the technical adeptness to fix the cause or the problem doesn’t happen enough to be a substantive issue.

What’s up with these Blue Screens?

Most Blue Screens are a corollary of bad software drivers or hardware compatibility.  Whenever the computer freaks and barfs up the Blue Screen it dumps the data in memory to a special dump file.

Unfortunately the file is both recondite and large; however, it does contains clues about the root cause of the crash.

By default, Windows dumps the contents of RAM to a file called MEMORY.DMP.  But if you try to read it in Notepad, your mind will dissolve into a gooey mass of Jello.

Unless you have some occult knack for deciphering hexadecimal, you’ll need some sort of memory dump analyzer to make sense of this mess.

If the dump is less than 40MB you can just upload it to OSROnline and analyze it right in the browser.  But if your hapless file is greater than that you’ll need to go through a slightly more onerous process.

Thankfully it’s not going to be difficult for you because, by the end of this article, I’ll have you reading these abstruse crash dumps like a bona fide lab-coat wearing computer scientist.

Check it out…

First up we need to install Windows Debug (colloquially known as WinDbg for slothful typists)

Type on over to the Windows Development Center then scroll down until you see the section entitled “Standalone Debugging Tools for Windows (WinDbg)”

Since I’m running Windows 8.1, I picked the Windows Development Kit (WDK) for Windows 8.1 on the left.  Conversely, if you’re running Windows 7, Vista or XP, you should grab the standalone debugging tools for Windows XP as part of Windows 7 SDK.

It’s in the right column of the below image.

Run the setup file and keep marching through the setup screens until you can choose the features you want to install.

We only want Debugging Tools for Windows so everything else is superfluous.

Finish the installation and launch WinDbg.

Bam!

The austere WinDbg interface is enough to negate the nascient hope in the hearts of newbies.

I agree, the screen is formidable but we’re about to tackle it head on.

Have no fear, I’m about to show you how to kick ass with WinDbg.

Finding the dump

The first thing we need to do is find that elusive MEMORY.DMP file.

Conventionally the memory dump lives in the C drive root but sometimes you’ll find it lurking in C:\Windows\minidumps or just C:\Windows.

Set the Symbol Search Path

We’re about to open the crash dump for analysis but before we do that we need to make sure we tell Windbg the path to the Microsoft Symbols Server.

Crash dumps show you a list of functions that executed moments before the crash.  This function list is known as a stack trace; however, without the symbol files the debugger can’t resolve the function names, parameters or local variable stored in memory. And although it’s possible to view some information on the stack without that symbol file, the data will be inconclusive and consequently unreliable.

Thus, we need to enter a Symbol Server so the debugger knows how to construe the crash dump.

Fortunately this is very very easy.

In the WinDbg application press Ctrl + s to open the Symbol Search Path window.

Now paste in the following symbol path and click OK:

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

Excellent.

Now click the File menu and choose Save Workspace. This saves the symbol search path so you don’t need to enter it again.

Opening the Crash Dump

Now hold your breath for a few seconds and press Ctrl + d to open the crash dump.

Pump your fist in the air twice like The Situation from Jersey Shore because we can now read the contents of the dump.

Yes, I know it’s still obscure but that’s okay because we don’t need to understand everything that’s going on here.  We’re just looking for a very specific thing: a culpable driver or process that appears to have triggered your grumpy blue screen.

Click the blue !analyze -v link or manually type it in the text box along the bottom edge of the screen.

The output updates and spits out some very telling results.

I know it’s hard to read but pay attention to keywords such as:

• Probably cause by
• DEFAULT_BUCKET_ID
• PROCESS_NAME
• IMAGE_NAME

If you see the “Probably caused by” phrase then the filename that follows is most likely the culprit.  A quick Google search will tell you which application it belongs to – then you can make a prudent decision to either update that application or uninstall it.

The DEFAULT_BUCKET_ID, PROCESS_NAME and IMAGE_NAME parameters are also good predictors of the problem source.

In my case, you can see a process named csrss.exe is at fault.

After Googling around for about a minute I discovered that csrss.exe it’s a legitimate Windows process but is often hijacked by Trojans.

Armed with a new lead I can now scan my computer for viruses and uninstall any recent programs to solve the issue.

The Bottom Line

I hope I’ve assuaged any trepidation you had about the Blue Screen of Death.

Blue Screens are scary stuff but understanding the causes doesn’t have to be.  Now that you know how to use WinDbg to analyze crash dumps you’re a step ahead of the problem and have augmented your skills with useful knowledge.

If my little article helped you please share in the comments below!