Terms of Use For FixedByVonnie

By proceeding to access fixedByVonnie.com, you expressly acknowledge, and agree to, all of the following:

fixedByVonnie.com is a personal website and blog owned by Security Plus Pro LLC, which is being presented for informational purposes only. The views on this website are solely those of the website owner (and not those of any employer or of any professional associations affiliated with the website owner).  Any views expressed in this website and any information presented on this website, or in any of its blog entries, should not be relied on for any purpose whatsoever other than as the personal opinions of the website owner.  The website owner expressly disclaims any and all liability for any information presented on this site.  The owner of this website and its blog posts shall not be held liable, and shall be held harmless, for any errors or omissions in any information or representations contained in this website, or in any of its blog entries.  The website owner also expressly disclaims any liability for the current or future availability of any such information. The website owner makes no representations as to the accuracy or completeness of any information on this website or which may be found by following any link on this website. The website owner shall not be held liable for any losses, injuries, damages, claims, or causes of action, from the display or use of any information on this website or in any of its blog entries. If you use the information on this website, or on any of its blog entries, you do so solely at your own risk.

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

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

Blue Screen of Death Attempted Execute of No Execute

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.

Trying to manually analyze the contents of the MEMORY.DMP file

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.

Windows Development Center

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

Windows Software Development Kit

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

Finish the installation and launch WinDbg.

WinDbg in Windows 8.1


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:


Windbg Symbol Search Path


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.

Viewing the MEMORY.DMP in Windbg

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

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.

WinDbg csrss.exe

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!


Connect with Vonnie on Twitter

Posted in Windows, Windows 7 Tagged with: ,