What are Dump Files?
It is essential for software engineers to know how to evaluate and process dumps in order to figure out why their program is failing or acting strangely. However, deciding where to begin the process can be difficult.
This post can serve as an excellent starting point for debugging a crash dump file when you are running a.NET application on Windows operating system.
Table of contents
- What are dump files?
- Types of dump files
- How to automatically capture the crashing process of dump files?
- How to create a dump?
- Investigating dumps with Visual studio
- Investigating dumps with Windbg
What are dump files?
Memory Dump Files (.dmp files) are snapshots of a program's memory taken at a certain point in time, such as during a crash. You can see -
- The current executing lines of code
- The values of local values
- The values of all heap objects in a dump file.
In other words, a dump file contains the complete state of the program at the time it was captured.
Dumps are commonly used to troubleshoot crashes (Crash Dumps), but they can also be utilized for other purposes. Here are their uses (in order of most common to least common) -
- Debug crashed programs
- Debug hung programs
- Find memory leaks
- Debugging on a different machine or even debugging at a different time
- Debugging programs that cannot be attached to a debugger
- Debugging with WinDbg
Types of Dump Files
Full Memory Dump and Minidump are the two forms of dump files. A Full Memory Dump comprises the whole memory of the program. It often gets huge in terms of space.
The term "minidump" is deceptive. It's a dump format that can be customized. It can either contain all of the memory, taking up as much space as a full memory dump (and possibly more) or can simply contain a portion of the memory per configuration.
We'll usually use Dumps with the entire RAM for.NET to get a complete debugging experience. It can be a full memory dump or a minidump with the entire memory area included.
How to automatically capture the crashing process of dump files?
You must adjust registry settings to enable the dump file because it is not created by default. To enable the capture, you have two options. The first option is to set up the postmortem debugger settings.
In the first option, you first select a debugger application, such as Visual Studio, ProcDump, WinDbg, or ADPlus, and then the command switches for the programs to create a dump file or attach to the process for live debugging if they support it.
The second option is to set WER to create a dump file for your individual program in the event that it crashes. If you don't need live debugging and only need the dump file created on disc for later analysis, this is the way to go. Because this feature is built into Windows, no additional software is required to make the dump. The following are the registry settings for WER dumps:
If it doesn't already exist, build the base WER local dump registry key.
- HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps
Then, create the key for application-specific dump file settings.
If HelloWorldCrasher.exe is the application to save dumps for, then do the following:
New Key: HKLM:\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps\HelloWorldCrasher.exe
Registry values under this key:
- DumpFolder: [REG_EXPAND_SZ] folder path to store dump files.
- DumpType: [REG_DWORD] Specify a value of 2 for full dumps. 1 for mini-dump (smaller, but not the entire process memory space).
- DumpCount: [REG_DWORD] the number of dumps to save prior to overwriting the old dump files. The default value is 10.
Re-run the executable file for the hello world crashing application after you've configured these settings in the registry. When it crashes this time, a dump file should be written on disc in the folder we specified.
How to create a dump?
A Dump can be created in a variety of ways. Here are a few of the most popular and recommended ones:
- While debugging with Visual Studio
Go to Debug | Save Dump As... when debugging.
With Heap, you'll be able to save a minidump that includes the entire memory space.
- Make use of Task Manager.
Right-click the desired process and select Create dump file from the Task Manager's Details menu. This will result in a complete memory dump.
- Make use of ProcDump.
ProcDump is a component of the SysInternal toolkit, a collection of incredibly helpful Windows development tools. The command-line utility ProcDump is used to create dumps. It can create dumps on-demand or watch a program and generate a dump if it crashes or hangs.
- With Process Explorer
Another tool in the SysInternal toolset is Process Explorer. It's a Task Manager that’s one level higher. You can examine active Threads, registry entries, and, of course, build dumps to see which processes loaded a specific DLL or Handle.
Choose Create Dump | Create Full Dump... from the context menu of any process.
Debugging dumps with Visual Studio
The most straightforward method to explore dump files is to open the Dump File (.dmp) in Visual Studio. You'll create a wonderful debugging experience if you can match the Symbols (.pdb files) and Source Files. That is, the code will seem to you as if you were standing on a breakpoint. You'll notice the Exception that caused the crash if it was a Crash Dump. Threads, Call Stacks, Locals, Loaded Modules, and so on should all be visible.
Steps to debug with Visual Studio:
- In Visual Studio, open the .dmp file.
- Choose “Debug with Managed Only” or “Debug with Mixed” from the drop-down menu that appears.
- Wait for Visual Studio to attempt to load symbols and compare them to the source code.
- The code will appear if symbols were loaded. Otherwise, the call stack, exception information (if collected on exception), and possibly local values should be visible.
- Investigate the exception or problem as though you were debugging in Visual Studio.
Investigate dumps with Windbg
When it comes to investigating Dump files, WinDbg is the preferred tool for most people.
Visuals Studio is still catching up in terms of capabilities. WinDbg can examine the object heap, extract modules, locate deadlocks, and do a lot of other things that VS can't.
If you're unfamiliar with WinDbg, it's a Windows debugging tool that mostly uses the command line. With the SOS debugging extension, WinDbg may be used for native programs as well as managed.NET ones.
In 2021 you have a plethora of tools at your disposal to make debugging considerably easier. Visual Studio, DumpMiner, SuperDump, and WinDbg Preview are just a few of the tools available to you today. You can find many other tools to give you a 360-degree view of your programs.