This blog entry deals with user mode dumps only. Kernel mode dump files is not dealt with here but should be quite similar.
Define dump file
It is the memory snapshot of a process. The dump file saves all information pertaining to a process. The information include, loaded modules/dlls, handles, executing threads and other stuffs. Optionally we can include heap information.
How to open a dump file?
Dump files can be opened in a debugger as you would normally open a process or attach to a process. All debuggers provide options for opening a dump file. Here is the menu option in WinDbg which opens a dump file…
A similar but, kinda hidden, version of open dump file option in Visual Studio, its not so visible unless you dig a bit. See below screenshot…
How to create a dump file?
A quick option which is quite is limited is to use the task manager “Create Dump File” option. Which looks like…
With windbg use the .dump /ma D:\DumpFile.dmp command. With visual studio you can attach to a process and use Debug->Save dump as or while you are debugging use Debug->Save dump as.
Another tool that comes along with “Debugging tools for windows” is ADPlus, a VBScript based tool, which automates the process of creating a dump file. This tool works by using cdb.exe (console debugger) command line options. Very powerful. I’ll blog about the tool in another post.
Limitations of dump files
You cannot execute the dump file, just like you would normally do with a process, or set breakpoints; a dump is a ‘snapshot’ of a process at a particular point of time. So all stuff in memory up till that particular point of time will be available but not after that particular point of time. Also if you have a wrong dump file then you could end up wasting time, so in order to prevent such cases we have tools like ADPlus which when setup properly automates the process of capturing dumps.
Different kinds of dumps
- Crash dump – automatically taken during a crash
- Hang dump – automatically taken (using tools like ADPlus)
- High CPU dump – automatically taken (using tools like ADPlus)
Dump file tips in windbg
- I normally execute the following command in WinDbg: !analyze -v. This command gives a summary of the stuff in dump file. So it shows you the stack of the thread in which the exception occurred.
- Also when you open a dump file in WinDbg you’ll get a brief summary of the exception that occurred and also a view of the registers.
- If you have a hang dump or a high CPU dump you will love the following command: !analyze -hang. This shows us the name of the function which is eating up most of CPU time.
- You will love the command !runaway which shows the excecution time for each thread, so this way you can identify the thread that’s taking most of CPU time.
- To know the type of dump file you are working on enter “||” into WinDbg. This command will tell you whether you are dealing with a full dump or a mini dump. A sample output on a dump of MsPaint.exe looks like…
0 Full memory user mini dump: D:\MsPaint.dmp
- To know the name and id of the process for which this dump was made use the single pipe command “|”. Sample output looks like…
0 id: 11e4 examine name: C:\Windows\System32\mspaint.exe
- .ecxr gives you exception record along with registers display.
- .lastevent shows you the last exception that occurred.
- You can create a mini dump out of a full dump by executing a .dump filename command on the existing dump.
- To view last error status of all threads use !gle -all
- Its very important to have the correct pdb files. Public symbol path and downstream store path should be set in WinDbg or by using _NT_SYMBOL_PATH environment variable. This is how mine looks -> SRV*C:\DebugSymbols*http://msdl.microsoft.com/download/symbols
- Don’t forget you are doing “post mortem” debugging. The dead doesn’t walk and talk. 🙂
- ~* kpn shows stack of all threads
- !locks displays locks held by threads
- !lmvm ModuleName display information about a module. !lmvm User32 display information about user32.dll.
- lm sm display all modules loaded/unloaded in sorted order, ‘when’ the dump was taken.
- lm or lmvi display all modules loaded/unloaded in their load/unload order
- dt command displays type information of a type passed in.
- dv command displays all local variables
- x to examine a symbol. For e.g. to see all symbols in kernel32 starting LoadLibrary use following command: x kernel32!LoadLibrary*. The output looks like…
00000000`77906640 kernel32!LoadLibraryExWStub = 00000000`778fe3b0 kernel32!LoadLibraryExAStub = 00000000`77907058 kernel32!LoadLibraryExA = 00000000`77906f80 kernel32!LoadLibraryW = 00000000`77907070 kernel32!LoadLibraryA = 00000000`77906634 kernel32!LoadLibraryExW =
Have fun debugging dump files and help others too. Spread word about this article. If you’ve got comments let me know. 🙂