Login/Register
How to use WinDbg to analyze the crash dump for VC++ application?
Asked Answered
Solved c++visual-c++windbgcrash-dumps
B

4

48

How do I use WinDbg for analyzing a dump file?

Bridgeport answered 9/4, 2009 at 13:38 Comment(0)
N
74

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 Visual C++ compiler do this by default, but in many versions of Visual C++ 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 applications has its own set of PDBs. You can't just reuse the same ones you made with build 10 to examining 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 a 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 that you have received the dump file from the customer, you know the precise version of the application 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/Visual C++:

  1. Get the complete source tree for that version of your application. Put it in a separate 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 application to get the binaries.
  3. Put the PDB files in the same location as the binaries in step 2.

Now you have two options for viewing the dump file. You can use Visual Studio or WinDbg. Using Visual Studio is easier, but WinDbg is much more powerful. Most of the time the functionality in Visual Studio 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 of 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 or 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 into your application's memory space, the state of critical sections, windows, etc. But that is way beyond the scope of this post.

Good luck!

Nickel answered 17/4, 2009 at 3:5 Comment(6)
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? – Bridgeport
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. – Nickel
Using symbol indexing and source indexing will ease the work to locate the matching PDB and source code. Besides, the indexing supports both Visual Studio and WinDbg. – Splitlevel
@Thomson: I'm not sure I know what you're talking about, but if you could elaborate via an answer I bet that would enhance this question a great deal. This question gets a lot of views. – Nickel
@JohnDibling, thanks. This link (blogs.msdn.com/b/buckh/archive/2011/04/11/…) will help explain the concepts of indexing. In brief, the image and PDB can be associated by a GUID generated at compile time, so store PDBs for all released binary into certain structure, then WinDbg can locate the correct version correctly. Source indexing is recording the source code version and source control server into PDB, so the right version can be opened automatically by WinDbg when PDB with private symbols are loaded. – Splitlevel
Is it possible to create a .PDB file without adding lots of debug info to the binaries at the same time? – Frederiksen
S
42

(see the "Dump" sections below)

Basic Tutorials and Demonstrations of Using WinDbg

Different Ways to "Start"/Attach WinDBG

Workspaces

Understanding how Workspaces work...

Cmdtree

A "cmdtree" allows you to define a "menu" of debugger commands for easy access to frequently used commands without having to remember the terse command names.

You don't have to put all the command definitions into the same cmdtree text file....you can keep them separate and load multiple ones if you wish (they then get their own window).

Startup Script

You can use the -c option on the command line to automatically run a WinDBG script when you start WinDBG.

Gives opportunity to turn on DML (Debugger markup language) mode, load particular extensions, set .NET exception breakpoints, set kernel flags (e.g. when kernel debugging you might need to change the DbgPrint mask so you see tracing information....ed nt!Kd_DEFAULT_Mask 0xffffffff), load cmdtrees, etc.

An example script:

$$ Include a directory to search for extensions
$$ (point to a source controlled or UNC common directory so that all developers get access)
.extpath+"c:\svn\DevTools\WinDBG\Extensions"
$$ When debugging a driver written with the Windows Driver Framework/KMDF
$$ load this extension that comes from the WinDDK.
!load C:\WinDDK\7600.16385.1\bin\x86\wdfkd.dll
!wdftmffile C:\WinDDK\7600.16385.1\tools\tracing\i386\wdf01009.tmf
$$ load some extensions
.load msec.dll
.load byakugan.dll
.load odbgext.dll
.load sosex
.load psscor4
$$ Make commands that support DML (Debugger Markup Language) use it
.prefer_dml 1
.dml_start
$$ Show NTSTATUS codes in hex by default
.enable_long_status 1
$$ Set default extension
.setdll psscor4
$$ Show all loaded extensions
.chain /D
$$ Load some command trees
.cmdtree c:\svn\DevTools\WinDBG\cmdtree\cmdtree1.txt
.cmdtree c:\svn\DevTools\WinDBG\cmdtree\cmdtree2.txt
$$ Show some help for the extensions
!wdfkd.help
!psscor4.help
.help /D

Command Cheat Sheets

Extensions

"Extensions" allow you to extend the range of commands/features supported inside WinDBG.

Write your own extension

Using WinDBG to Debug Managed Code

Scripting (C#, PS, Python, WinDBG)

Debuggers/Tools that use the dbgeng.dll API/WinDBG Tools

Different Ways to Generate Crash Dump Files for Post-Mortem Analysis

Dump Analysis Tools

Dump related Tools

  • Citrix dumpcheck - checks consistency of dump file (looks like it's been abandoned link + link)
  • dumpchk (part of Debugging Tools) - checks consistency of a Dump file
  • MoonSols Windows Memory Toolkit (formerly windd) - converts various raw memory dump files into WinDBG compatible dmp files
  • vm2dmp - Microsoft Hyper-V VM State to Memory Dump Converter
  • vmss2core - converts VMWare snapshot file into a core dump file (download), (instructions)

Kernel Debugging Virtual Machines

  • VMKD - Virtual Machine KD Extensions
  • VirtualKD - (kernel debugger support for OS's hosted in VMWare/VirtualBox)

Videos

Blogs

Some blogs (mixture of native and managed code debugging).

Advanced Articles and Tutorial Resources

Alternative Debuggers

Other Links

Sills answered 9/8, 2014 at 21:2 Comment(1)
I have just bookmarked this page for your answer..!! :) – Neruda
R
5

This is a really broad question.

  1. The first step is to load the dump file into a WinDbg instance.
  2. Next, you need to make sure you have a symbols setup.
  3. Finally, you can run the 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 worthwhile.

The website Memory Dump, Software Trace, Debugging, Malware, Victimware and Intelligence Analysis Portal has been very informative for me. I also really enjoyed the book, Advanced Windows Debugging by Mario Hewardt and Daniel Pravat.

Repetend answered 9/4, 2009 at 16:23 Comment(0)
S
3

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

Samuel answered 11/4, 2009 at 4:27 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.