通过

Special Command—Using .dump/.dumpcab to Get Dumps and Symbols from Production Servers

  • 项目

Using WinDbg you can create a dump file from an application running, for instance, in a production server. After collecting the dump file, you can load it in another machine and debug it. However, to be more effective during your debugging session you need symbols. Thus, thinking about it, here's the trick to get both dump and symbols.

 

First, to get a dump file with all information use it:

 

0:000> .dump /mfht c:\Test.dmp

Creating c:\Test.dmp - mini user dump

Dump successfully written

 

.dump has several arguments, but if you want a mini-dump with all information you just need to use:

/mfht

Where:

/m – This is to use options.

f – Adds full memory data to the minidump. All accessible committed pages owned by the target application will be included.

h – Adds data about the handles associated with the target application to the minidump.

t – Adds additional thread information to the minidump. This includes thread times, which can be displayed by using the !runaway extension or the .ttime command when debugging the minidump. (now you understand why your !runaway command failed that day, huh? :) )

 

Note: For more arguments check the WinDbg help file.

 

After collecting the dump file, open it from the production server using WinDbg and reload the symbols again.

Go to the command line and use the .dumpcab command.

The arguments for .dumpcab are –a (force all symbols) and the file name itself.

Here is how to do that:

 

0:003> .dumpcab -a c:\fulldump

Creating a cab file can take a VERY VERY long time

.Ctrl-C can only interrupt the command after a file has been added to the cab.

  Adding C:\test.dmp - added

  Adding c:\publicsymbols\wntdll.pdb\E06BEA155E9748BEA818E2D0DD2FED952\wntdll.pdb - added

Wrote c:\downloads\fulldump

 

After doing that the file FullDump.CAB will have the dump file and all related symbols, so you can transport it to your machine, unpack, load the dumps/symbols, and start debugging it!

Comments

  • Anonymous
    September 17, 2009
    I thought Windbg would use the MS symbol server to get the correct symbols no matter the OS you're on at the moment. IOW, if I'm debugging a dump file created on Server 2003 but I inspect it on my XP dev machine, Windbg will get the ntdll.pdb for Server 2003, not XP. Is that right?

  • Anonymous
    September 17, 2009
    You're right, however, you won't get the symbols for the specific application you're debugging. The technique I wrote above is used to get the application symbols when collecting the dump file. After doing that you open the dump in your machine, load the public symbols from Microsoft and the application symbols that came with the dump file. Here is a diagram: Production server -> WinDbg to collect dumps using .dump Production server -> WinDbg to collect application symbols using .dumpcab. At this point if there are public symbols for Windows in the production server they will be saved too. Development server -> WinDbg to open dumps from production server. Development server -> Windbg  to load application symbols that came with the dumps. Development server -> Windbg to load public symbols (.symfix). When you do that you have the public symbols that matches the dump and the application symbols that matches the dump. Thanks for the question.

  • Anonymous
    November 03, 2009
    Just a small note , in real life , customers should not have your binaries symbols ever.