views:

6141

answers:

4

Hi

Any one knows how to use the windbg for analyzeing dump file. Please share the info how to analyze crash dump using windbg.

Thanks, Haranadh

+2  A: 

This is a really broad question. The first step is to load the dump file into a windbg instance. Next you need to make sure you have symbols setup. Finally you can run the following command !analyze -v to get a basic analysis performed on it. You need to have symbol information available for your code to make dump files worth while

The following website has been very informative for me, http://www.dumpanalysis.org/. I also really enjoyed the book, Advanced Windows Debugging.

LanceSc
+1  A: 

Tess Ferrandez has a great set of basic tutorials and labs to get started with Windbg. I highly recommend them.

http://blogs.msdn.com/tess/pages/net-debugging-demos-information-and-setup-instructions.aspx

womp
+6  A: 

Here are some general steps that will get you on your way:

First, you must change your compiler's settings so that it creates PDB files, even for release builds. Later versions of the VC compiler do this by default, but in many versions of VC you must do this yourself. Create program database files, and then keep an archive of those files along with each build of your application. It is critical that every build of your app has it's own set of PDBs. You can't just reuse the same ones you made with build 10 to examing the dumps generated by build 15, for example. Over the life of your project, you will end up with a ton of PDBs, so be prepared for that.

Next. You need to be able to identify the exact version of your application which generated the dump file. If you are creating your own minidumps (by calling MiniDumpWriteDump() for example), probably the easiest way to do this is to simply make part of the filename of the MiniDump the complete version number of your application. You'll need to have reasonable version numbering scheme in place for this to work. In my shop, we increment the build number across all branches by one every time the autobuilder creates a build.

Now. You have recieved the dump file from the customer, you know the precise version of the app that created the dump, and you have found the PDB files for this build. Now you need to go through your source control's history and find the source code for this exact version of the software. The best way to do this is to apply 'labels' to your branches every time you make a build. Set the value of the label to the exact version number, and it becomes easy to find in the history.

You're almost ready to fire up WinDbg/MSVC:

  1. Get the complete source tree for that version of your application. Put it in a seperate place on your hard drive, say c:\app_build_1.0.100 for application version 1.0 build #100.
  2. Get the binaries for that exact version of your application and put them somewhere on your hard drive. It might be easiest simply to install that version of your app to get the binaries.
  3. Put the PDBs in the same location as the binaries in step 2.

Now you have 2 options for viewing the dump file. You can use VisualStudio or WinDbg. Using VisualStudio is easier, but WinDbg is much more powerful. Most of the time the functionality in VS will suffice.

To Use Visual Studio, all you have to do is open the dump file like it is a project. Once opened, "run" the dump file (F5 by default) and if all the paths are set correctly it will take you right to the code that crashed, give you a call stack, etc.

To use WinDbg, you have to jump through a couple hoops:

  1. Start WinDbg
  2. Open the dump file. (Ctrl-D by default)
  3. Tell WinDbg to go get the correct MicroSoft symbol files. Type ".symfix" This may take a few moments as it will pull a ton of stuff down from the internet.
  4. Tell WinDbg where the symbols (PDB files) are. type ".sympath+ c:\pdblocation" substituting wherever you put the PDB files for the pathname. Make sure you get the plus sign in there with no whitespace between .sympath and the + sign else you'll screw up step 3.
  5. Tell WinDbg where the source code is. Type ".srcpath c:\app_build_1.0.100" substituting the path where you got code from source control for this version of the software.
  6. Tell WinDbg to analyze the dump file. Type "!analyze -v"

After a few moments, if everything is configured correctly, WinDbg will take you right to the location of your crash. At this point you have a million options for digging deep in to your app's memory space, the state of critical sections, windows, etc. But that is way beyond the scope of this post.

Good luck!

John Dibling
Thanks a lot for detailed info. I will try your steps, Is .symfix will give any output. how can we know that command execution completed or not?
Haranadh
There is a *BUSY* indicator in the status bar that tells you when WinDbg is busy processing your command. Other than that, unless you get an error message you will not get a response that says the command completed. Pay attention to the output from !analyze -v however. If you don't have the right PDBs for any modules, it will complain.
John Dibling
This was extremely helpful. Thanks!
kizzx2
A: 

Step by step guide on how to Analyse a dump file:

http://clintboessen.blogspot.com/2009/12/how-to-analyze-dump-file.html

Clint