Analyzing a Mini-Dump using Visu

Creating a Mini-Dump using the Mini-Dump tool and Analyzing it in Visual Studio 2003

Requirements:
a. Visual Studio 2003
b. Mini-Dump Tool
c. TestDump.zip (Test project)

Running your code in a test environment is the ideal way to debug an application but sometimes this is not possible. Sometimes deadlock issues are very hard to reproduce in a test environment. This is the reason I created the Mini-Dump tool and written this tutorial. This tutorial will show you how to create a mini-dump using the mini-dump tool then open it in Microsoft's Visual Studio to analyze it. I have included a sample application with this article so that you can follow along as we go.

Creating the Dump File

Download the above sample project, open it in visual studio, build it and run it. The application will stay running forever because the code contains an infinite loop. Open the Mini-Dump tool while the application is still running, find the TestDump.exe process in the process list, right click and choose create mini-dump. This will create a mini-dump and save it to the dumps directory.

Analyzing the Dump File

Open Visual Studio and select open solution from the file menu.

Change the file type to "Dump Files (*.dmp; *.mdmp)."
Navigate to the dumps directory and choose the dump file you wish to analyze.

Once you open the dump file you can start debugging by select Start from the Debug menu.

After running the solution you will be prompted to save the .sln file. Just save it anywhere.

Once the solution is saved you are now able to see where you application was when the dump was created. You can not step in to the code because it's not actually running the dump is only a snapshot of the process at the time created. What it will allow you to do is view each thread and it's call stack.

If you have the PDB files (debug symbols) you will see the actual names of the functions in the call stack. In the below stack trace you see function addresses instead of names for ntdll.dll because there are no debug symbols available . On the other hand if you look at the Kernel32.dll and TestDump.exe you see function names because the symbols are available.

If you click on a function in the call stack you will see the disassembly open in the main window. If you have the source files you can right click in the disassembly window and select view source to change to source code view. If you run the included sample using the Mini-Dump tool you will see the below source view in the debugger.

As you can see from this view its easy to find the cause of your infinite loop.

You should be aware that to examine the code that was running on the computer the dump was taken from, the debugger must be given access to the same binaries that the that computer was running. The debugger uses the name and time stamp stored in the mini-dump file to uniquely match and load the binaries. If you do not have the exact matching image the call stack may be incomplete. To keep track of your images and symbols you should take a look at Microsoft® symbol server, it makes this task a lot easier.

Please send any comments to minidump@atwill.com.

Back to home page