Please do not post your BSOD related issues here, or PM me with any questions, ask them here. If you're having blue screens and would like them analyzed, post a thread in the Crash Analysis and Debugging forum as this thread is strictly for learning how to analyze and debug dump files at the most basic level. You're also more than welcome to PM'ing me if you need a crash dump file analyzed / BSOD related assistance. Thanks
** Last updated 8/20/2013
pjBSOD, what's the point of this thread, why did you even make this guide?
It's very simple, actually. I made this thread because blue screens are and have always been a huge problem, and a VERY large number of PC users (even PC Enthusiasts and builders) don't know how to analyze dump files to troubleshoot their issues, or the issues of a family computer, etc. Growing up and using computers, when I got BSOD, it was the end of the world to me. I'd see this blue screen with a bunch of numbers and technical mumbo jumbo, and none of it made sense to me, because to me, it was just "Oh crap, I'm screwed, I have no idea what to do.. I think I'll just reformat if it gets really bad", and this is unfortunately the case with a lot of people. Some people don't even know how to reformat a computer, or have access to a disk, so they pay a Geek Squad or some other local repair shop HUNDREDS of dollars to reformat a computer.
Another big reason I made this guide is because analyzing and debugging crash dump files should not be a secret, it should be available to read and learn on every computer forum.
pjBSOD, why should I learn how to debug dump files with WinDbg if there are programs like BSV (Blue Screen View) out there?
I go into my personal opinion / rant on BSV later in this post, you can read it there.
This guide will not turn you into a Crash Dump Analysis Guru. For example, you won't be like that guys that work at Microsoft that can take a look at a stack of memory in a dump and go "Okay, here's what caused it", or like the various MVP's across forums that are expert analysts, etc. This is simply a beginner guide I have written and compiled to give you a head-start / idea. Knowledge like that with this takes years of schooling, years of reading over dump files to get used to it and learn it.
If you truly want to be one of those people, all it takes is practice and a will to learn and work for it like everything else. Hang out around BSOD sections on forums, read blogs, study bugchecks and their usual causes, see popular culprits, etc. It's all a matter of practice and a will to learn.
Alright, sounds good, where do I begin and what do I need to analyze dump files?
A) You're going to need the Windows Debugging Tools, or better known as "WinDbg". Download the appropriate tools for your version of Windows from here.
If you're running 32 bit Windows, download the 32 bit Debugging Tools. If you're running 64 bit Windows, download the 64 bit Debugging Tools. You'll still be able to debug x64 dumps if you've installed the x32 bit, same with x64 and debugging x32 dumps.
B) Once you've downloaded and installed the Windows Debugging Tools, you have to configure WinDbg before you start analyzing dumps. The most important part of configuring the debugging tools is the symbol path, so pay attention:
1. Open WinDbg, but do not open any dump files, just open WinDbg.
2. Go to File>Symbol File Path or alternatively hit Ctrl+S.
3. Set the Symbol File Path to:
4. Click "Ok" and exit WinDbg.
5. It should ask you if you'd like to save the workspace, click "Yes".
Basically, in short, we set this symbol path because it caches each symbol it has to download from the Microsoft symbol server. So, rather than taking forever to load a dump file, since it has already been cached in the past, it will load quickly so you can get to analyzing faster. Do note that the Microsoft symbol file does NOT contain 3rd party drivers, but we'll get to that later.
C) There are other OPTIONAL things you can setup for your WinDbg. If want to get right to analyzing, skip this.
1. One optional thing you can do is setup WinDbg to be the default application / program for crash dump related files. I really recommend doing this as instead of having to open up WinDbg, hitting Ctrl+O to open a dump, etc... you can easily just double click the dump file in question and WinDbg will take care of the rest. In layman's terms, it saves a ton of time. Thanks to H2S04 over at SevenForums for this option!
- Run CMD as admin (elevated command prompt)
C:\> cd debuggers
(If it doesn't change directory automatically, you'll have to specify the entire path... for example, I type the following to get to my windbg:
cd \ (this will send you to root)
cd program files (x86)\windows kits\8.0\debuggers\x86
Once inside specified .EXE directory, type the following:
C:\program files (x86)\windows kits\8.0\debuggers\x86> windbg.exe -IA
- In response, WinDBG should pop up a dialog box that says this:
WinDbg successfully registered file assocations for .DMP, .HDMP, .MDMP, .KDMP and .WEW.
pjBSOD, I've set all of this up, but for some reason crash dumps aren't being generated! What should I do?
Ensure and know the following things first:
- In order for crash dumps to be written, your Page file must be on the OS drive.
- Page file allocation size must be greater than the physical amount of installed RAM. Also ensure that the Page file is set to system managed.
If you're curious and how to get more info on your Page file, there's two methods of doing this:
1. Run CMD as admin (elevated command prompt) and paste / type the following:
2. Paste / type the following into the Windows search box:
Quick in-depth tutorial on how to ensure dumps are being generated:
1. Start > type %systemroot% which should show the Windows folder, click on it. Once inside that folder, ensure there is a Minidump folder created. If not, CTRL-SHIFT-N to make a New Folder and name it Minidump.
2. Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Performance > Settings > Advanced > Ensure there's a check-mark for 'Automatically manage paging file size for all drives'.
3. Windows key + Pause key. This should bring up System. Click Advanced System Settings on the left > Advanced > Startup and Recovery > Settings > System Failure > ensure there is a check mark next to 'Write an event to the system log' > Ensure 'Automatically restart' is un-checked.
Ensure Small memory dump is selected and ensure the path is %SystemRoot%\Minidump.
4. Double check that the WERS is ENABLED:
Start > Search > type services.msc > Under the name tab, find Windows Error Reporting Service > If the status of the service is not Started then right click it and select Start. Also ensure that under Startup Type it is set to Automatic rather than Manual. You can do this by right clicking it, selecting properties, and under General selecting startup type to 'Automatic', and then click Apply.
Regarding Blue Screen View:
*Note that I'll be abbreviating Blue Screen View with BSV.
BSV, where do I even begin. Well, first off, I should probably say that BSV in layman's terms is a simplified WinDbg. With that said, it misses a lot of information that WinDbg provides that will help you solve BSOD related issue. For example, one of the very basic things you cannot do out of the many compared to WinDbg, is you cannot view the currently loaded modules / drivers at the time of the crash from that specific dump. This is very important because the "probably caused by", PROBABLY BEING THE KEYWORD, is not always the key to solving BSODs. There are also many other examples, but the modules one is a big one / easy one to mention.
With this being said, BSV is a great program, so hats off to the creator(s), however, for fully accurate debugging and analysis, the best way to go is WinDbg, especially if you want to learn.
An important thing to note about assisting individuals that are having BSOD's / something to think about:
I can assume you're reading this guide for two main reasons. Either it's one out of the two or both, and that's to analyze dump files yourself and gain personal knowledge, and to learn to analyze dumps files to assist others who are having issues. With the latter in mind, it's very important to be patient, respectful, calm, and VERY informative (don't be lazy and skimp out of details). This goes for BOTH parties, the user having the issue, and the person analyzing and debugging said crash dumps.
From an analysts point of view, it's very important that the user you're assisting is being respectful and is following your instructions carefully. The thing that's important to realize is crash analysis and debugging is mutual as I have mentioned earlier. If the user you're assisting is being informative and respectful, it makes it very easy for the person analyzing your dumps to do the same and provide the best assistance as you're being cooperative and following all of the instructions given to you.
Bottom line is, both parties need to maintain a bond of patience, respect and most of all, trust. If either is not, it makes the analysis very difficult and the user having the issues will likely not receive the best help possible, or any help at all. An important thing to note, if the user for whatever reason is being very disrespectful, will not cooperate, etc, simply make the choice of whether or not you'd like to continue helping this user, do NOT make it personal.
D) With all of this being said, once you have WinDBG's Symbol File Path all set up, we can now begin analyzing dump files! See the next post
Edited by pjBSOD - 8/20/13 at 3:19pm