We’ve all experienced it, the dreaded blue screen of death. With the dawn of Windows 7, these have become less prevalent, however they can (and do) still happen. Is it really the fault of Microsoft? I say nay nay!
Generally speaking, Windows 7, 8/.1, and the upcoming Windows 10, will only display a stop error (aka a BSOD, blue screen of death) when a hardware issue has occurred. Unlike previous versions of Windows, where a single application crash or freeze could take out your entire system, this is now a thing of the past.
Of course, this doesn’t mean the errors you may be receiving are innocuous. If you’re seeing a stop error, something is going on. To the trained and informed, this is easy to diagnose. However, to outsiders, it can seem like magic or witchcraft. Allow me to tell you: diagnosing your own stop error isn’t something you’d need a degree to do. You just need some simple tools:
- First and foremost, this article deals with some of the more advanced Windows components. If you are not comfortable tinkering with your computer, stop here. If you’re open to learning and patient, keep reading. Whichever you choose, I’m not liable for any damage you to do your system. 🙂
- A working computer with an active internet connection. If your computer is throwing constant, one after the other stop errors. This article may not be of help. However, you can always try to boot into safe mode with networking, and attempt what is described in this article.
- An installed copy of Windows Debugging Tools. You can download these here:
- If you have Windows 8 or 8.1, use the version found here: http://msdn.microsoft.com/en-US/windows/desktop/bg162891
- If you have Windows 7, use the archived version found here: http://msdn.microsoft.com/en-US/windows/desktop/ff851942.aspx
- Elect the “Get the Download” option under .NET Framework version 4. It will take you to the Microsoft download center where you can download the file.
- It’s possible there is minimal difference between the two versions (8/8.1 v. 7), however, I’m running Windows 7 and I’m using the version of the SDK from the archived version page. Thus, this article is based on that.
After the installer files have downloaded, do not run the installer. First, you must uninstall any/all copies of Visual C++ Resdistributable packages from your system. If you do not do this, the Windows Debugging Tools will fail to install. Open your Start Menu and navigate to Programs and Features, located inside the control panel. If you’re using Windows 8, go to the start screen and type “Uninstall a program”. When the list of presently installed applications opens, look for the following in the list and uninstall them:
Uninstalling these shouldn’t break any functionality on your computer. Most apps which rely on the packages will install them as needed anyway. And, the debugging tools will reinstall them, likely with different version numbers. No worries here!
Now, you can open the installer file you previously downloaded. Initially, it will scan your system to see what is already installed. You’ll see a window sort of like this: (Mine looks different because I’ve already installed the debugging tools).
As you can see, there are numerous options. If you only want the tools to troubleshoot blue screen errors, select the following:
- Visual C++ Compilers
- Microsoft Visual C++ 2010
- Debugging Tools
And click next, to install. You must have an active internet connection when trying this as the installer reaches out to Microsoft’s servers to download the most up to date files. The install time will depend on the speed at which your internet connection can download the files and how quickly your computer can process the installation.
Once the app is installed, look for the an application in your Start Menu > All Programs > Debugging Tools for Windows > WinDBG and open this app.
Initially, there’s not much to look at. It’s a fairly spartan application designed for but a few purposes. Before you do anything, however, you must set the symbol path. I’ve had to do this each time I use the application, however it’s possible it can be saved somehow. As I mentioned before, the application itself requires internet access as it will use the symbol URL to connect to Microsoft’s servers and pass the contents of your minidump file to their server for analysis.
To set the symbol path, select File > Symbol File Path. Enter the following and select ok.
SRV*your local folder for symbols*http://msdl.microsoft.com/download/symbols
Where it says “your local folder”, this is a random location on your computer for the Symbol Server to place temporary files for local use. I usually use C:\Symbols.
It is possible to build your own local cache of symbols from the Microsoft servers, and there is information about this on this Microsoft support article.
Microsoft has published extensive information on how to interpret the small minidump files created when your computer experiences a stop error. As such, I won’t go into extreme technical details. For an easier read of the technology, go here. For a more in depth technical read, go here.
Now, to troubleshoot a minidump file. Minidump files are a miniaturized (as the name implies) version of what was in your computer’s memory when the error occured. There is a larger version, which I often prefer when troubleshooting, called memory.dmp. These are located in the C:\Windows\ folder. Note: Depending on your system configuration, the minidump.dmp file may be located in C:\Windows\Minidump. If you are experiencing consistent blue screen errors, you should know – each time the computer BSOD’s, the memory.dmp and minidump.dmp files are overwritten. In some cases, this can impede troubleshooting. There is a fix, however.
From your Start Menu, right click “Computer” > select Properties. Select Advanced System Settings and select the Settings button under the Startup and Recovery section. From here, disable (uncheck) “Automatically Restart” and “Overwrite any existing file”. It should look like the image to the right, when done.
The next part of this article is from memory, as I don’t have a memory.dmp or minidump.dmp on hand to show you. However, don’t panic! It may seem complex, but really, it’s not.
From the debugging application, windbg.exe, select File > Open Crash Dump. Navigate to the location where your minidump.dmp or memory.dmp files are located and open it.
A word for the wise: The application is not fast. It will seem like it’s stalled out, but it hasn’t. Be patient!
When you initially open a dmp file, it will show you information contained in the file. Most of it isn’t immediately useful. However, you’ll see the following:
Followup: MachineOwner ---------
kd> !analyze -v The !analyze-v is a "clickable link". Select this, and the application will reach out to the Symbol Server for more information. When it returns, you'll end up with something like this:
******************************************************************************* * * * Bugcheck Analysis * * * *******************************************************************************
Unknown bugcheck code (86427532) Unknown bugcheck description Arguments: Arg1: 000001db Arg2: 00000002 Arg3: 00000003 Arg4: 0000000b
Debugging Details: ------------------
LAST_CONTROL_TRANSFER: from f3e41fc0 to 804f4103
STACK_TEXT: afaab964 f3e41fc0 86427532 000001db 00000002 nt!KeBugCheckEx+0x19 WARNING: Stack unwind information not available. Following frames may be wrong. afaabba0 f3e4220b 860eb8b0 f3e45cf0 00000000 pavdrv51+0x7fc0 afaabc34 804ea221 86338030 861bf890 806ad190 pavdrv51+0x820b afaabc44 8055d0fe 861bf900 861322f0 861bf890 nt!IopfCallDriver+0x31 afaabc58 8055de46 86338030 861bf890 861322f0 nt!IopSynchronousServiceTail+0x5e afaabd00 80556cea 000000a0 00000000 00000000 nt!IopXxxControlFile+0x5c2 afaabd34 8052d571 000000a0 00000000 00000000 nt!NtDeviceIoControlFile+0x28 afaabd34 7ffe0304 000000a0 00000000 00000000 nt!KiSystemService+0xc4 00cdff70 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4
FOLLOWUP_IP: pavdrv51+7fc0 f3e41fc0 ?? ???
Immediately, it’s not apparent what caused the error. However, if you look under IMAGE_NAME and a few other areas, you’ll likely see something that is <something>.sys or <something.exe>. Also, under “Bugcheck Analysis” shouold be details of what happened to cause the error.
It takes some getting used to, a little practice, but with this information you can likely Google your way to success in troubleshooting.
Remember, this is an article merely on how to use the tool to get information, not how to read it. Reading bug analysis, memory dumps, and such is a bit of a science as the way they work is fairly high level. Hopefully this intro to the application is helpful!