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:
/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
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!