On occasion my computer crashes with a blue screen of death (BSOD) with a notice that it is creating a minidump. From my understanding these minidumps should tell me what is causing the BSOD. I have been able to find these minidumps alright but am having trouble reading the files as whenever I attempt to open the minidump file an “Access Denied” message appears. How can I open these files? The computer is running Windows XP.

When Windows crashes with a BSOD it can be configured to write-out a minidump file. This file contains information on the crash event which occurred that caused the BSOD. For the benefit of other users, you can enable the creation of a minidump by going to the “Start” menu > “Control Panel” and open the “System” control panel (you may need to first select the “Performance and Maintenance” control panel category). In the System control panel, click the “Advanced” tab and under the “Startup and Recovery” heading click the “Settings” button. Under the “Write debugging information” heading make sure that “Small memory dump (64 KB)” is selected. The small dump directory should automatically populate with a value. Write down this value as it defines the location to which the minidump will be saved (this is usually the C:\WINDOWS\Minidump directory, also written as %SystemRoot%\Minidump which simply means the system root drive and directory and then Minidump sub-directory).

Now that the minidumps have been configured we will move onto reading a minidump file following a BSOD episode. You may be getting the “Access Denied” message because you have not been using the correct utility to read the minidump files, so we will proceed to install the utility which can read these files. If the problem continues then there are some other methods we can use to resolve the “Access Denied” error.

First, you need to download the debugger utility to read the minidump files. This is a free download from the Microsoft website at www.microsoft.com/whdc/devtools/debugging/default.mspx . Click the link to download “Install Debugging Tools for Windows 32-bit Version”. This will take you to another page allowing you to download the latest version of the tools. You will notice that the latest version of the Debugging Tools is included in the Windows Driver Kit (WDK) so you will need to download the WDK which will also install the Debugging Tools. Once this has been installed, there will be a new program group on your Start Menu named “Debugging Tools for Windows” which contains all the newly installed tools. We wish to start the WinDbg tool which will allow us to open and view the minidump files. Go to the “Start” menu > “All Programs” > “Debugging Tools for Windows” and open “WinDbg”.

If you opened a minidump file now you will not get much useful information. Instead, you will likely receive a message saying “Symbols cannot be loaded because symbol path is not initialized”. This is because you have not loaded the symbol tables into WinDbg. To understand why you need to install these symbol tables we need to take a quick detour and explore how programs are translated from their original source (programming code), which a programmer or software engineer writes, into executable machine code. As you may be aware, programmers generally write software in a high-level language (such as Visual Basic, C#, Objective-C, etc). This is human-readable and understandable. As part of the code which the progammer writes, they use identifiers. These identifiers include program variables, names of functions, names of modules, etc. The identifiers are written in human-understandable language as this provides a degree of intrinsic documentation in the code. For example, the programmer may write a function called “calculateAreaOfRectangle(width As Integer, height As Integer)”. This function obviously calculates the area of a rectangle given a particular width and height. As such, whenever the programmer calls this function within the program it is pretty obvious what the function will do, thus we are using intrinsic documentation. However, when the program is compiled this high-level language is translated into low-level machine code (binary) so that the program can be executed on any computer which understands that machine code. These identifiers are not required for the program to execute – all the executing program cares about are the memory addresses where all these identifiers are stored, as the executing program thinks in terms of memory addresses rather than identifier names. As these identifiers are not required, they are removed from the compiled program (so that the size of the executable file is reduced). However, thought was given that these symbols may be useful if we wish to debug the program later, as without these symbol files we would only see the memory address of errors. It would be much better to see the identifier for an error.

Using our previous example, if there was a crash in calculateAreaOfRectangle then without symbol files we would only see the hex address of the memory which calculateAreaOfRectangle occupied (e.g. 0x 20000120) rather than the actual identifier name (i.e. calculateAreaOfRectangle) which would be much more useful.

Therefore, for debugging purposes some software manufacturers provide the symbol files for download. In this case, we can download the symbol tables for Windows as this will provide us with all the identifier names for our BSOD so that we can see more useful information about the cause of the crash. Be aware, not all software manufacturers provide symbol tables. The reason that Microsoft provides these tables for Windows is because people develop software and hardware using Windows and they may need to debug their own software, so the symbol files are useful. Furthermore, the BSOD crash is a crash in Windows itself, so the Windows symbol tables will be relevant for debugging the source of the crash.

Now that we understand the need for the symbol files we need to load the symbol files into WinDbg. These can be downloaded on-demand from Microsoft so you just need to tell WinDbg the location of the symbol files. Open WinDbg and go to the “File” menu > “Symbol File Path”. In the window that appears type the following location: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols . This will download the symbol files from the Microsoft website and store them locally in the c:\symbols directory.

Next, we will try to open a crash dump file using WinDbg. Go to the “File” menu > “Open Crash Dump”. Navigate to the directory holding the minidump files (usually C:\WINDOWS\Minidump) and open the relevant minidump file. WinDbg will get rather busy at this point in time, as it needs to load all the relevant symbols and also any binaries related to the minidump file (as the minidump file is, well, mini it does not contain any of the executable files contents within the dump file itself, so it needs to find the executable file and load that in separately).

If you receive an error message informing “ERROR: Symbol file could not be found. Defaulted to export symbols for…” then something has gone wrong with the symbol file download, generally either because the symbol address was mistyped in the “File” menu > “Symbol File Path”, your internet connection is not working, or a firewall has blocked the download. In the last case, if you disable the firewall this generally won’t fix the problem as it has already corrupted the download. If the problem was firewall related then the best solution is to delete the symbols cache directory on your computer (i.e. c:\symbols) and then reopen WinDbg and a dump file so that will trigger the symbols to download again.

You may also see a warning such as “ERROR: Module load completed but symbols could not be loaded for…”. This means that the minidump file contains a driver which is faulty, and the debugger has detected this driver. However, no symbol information is available for that driver. This is alright, as the drivers generally do not contain symbol information. The main thing is that the faulty driver has been identified – we do not care about what inside the driver caused the problem (as there is nothing we can do to fix that problem). We mainly just wanted to know which driver is problematic so that we can take remedial action.

Finally, we are now ready to analyse the dump file and see what is the problem. You should be presented with a prompt allowing you to input a command into the debugger. At the prompt type: !analyze –v . This will provide a bug check based upon the minidump file that has been provided. Look through the bug check until you find the heading “Debugging Details”. This provides all the debugging information in that minidump file, in a somewhat analysed format making it easier to understand. You are most interested in the following items:
• DEFAULT_BUCKET_ID: This provides a general category of fault. For example, if this is defined as DRIVER_FAULT then you have a fault with some kind of driver on the computer.
• IMAGE_NAME: This provides the actual module (in the case of a DRIVER_FAULT, the actual driver file name) which is causing the problem.

Once you have the IMAGE_NAME you have narrowed down the problem to a particular module. Completing a search online (using Google or like) may yield results about how to fix this problem, which may involve a patch or updated version of the drivers. So, this provides you with a very good starting point for resolving the issue as you now know exactly what module is causing the problem.

Finally, we should deal with the situation arising where you receive “Access Denied” messages when attempting to open the minidump files. If you still receive this message when opening the files from within WinDbg then there is definitely something wrong. In the first instance, try copying the minidump file to a different location (such as the Windows desktop). To do this, right-click on the minidump file that you wish to copy and select “Copy”. Then, go to the destination location and right-click in any empty space and select “Paste”. Try opening that copied version of the minidump file using WinDbg.

The next possible cause is a permissions problem with the folder containing the minidump files, or a permissions problem with the minidump files themselves. I am not comfortable with manually modifying the permissions on the minidump folder and files, since there should be no need to undertake that procedure. Therefore, at this stage, it seems the most likely possibility is something wrong with the security descriptors on the folder and/or files, which is the actual entity that stores the permissions entries. The best way to check and resolve such issues is to run the ChkDsk utility. Be aware, this will take quite a long time to run. Additionally, as a matter of course, because it is changing data on your drive and repairing problems you should backup all important data before running this utility in case something goes horribly awry and the computer drive becomes unbootable and unusable. Once you have backed-up all important data and wish to proceed, go to the “Start” menu > “Run” and type “cmd” (without the quotes) and click OK. In the command prompt window that appears, type the following “ChkDsk /r” (without the quotes) and press ENTER. Be aware that ChkDsk may start running but then report you need to restart the computer because files are in use. Should this be the case, restart the computer and ChkDsk will automatically recommence operation upon reboot. As I said, this could take a while so don’t start this procedure should you need to use the computer within the following few hours.