Enabling Crash Dumps

It’s easy to debug your program in your personal development environment, but if your program crashes when QA runs it or, if you’re unlucky, when your customer does, then you need to be able to get crash/core dumps so you can get some useful debug information to track down the error.


Crash dumps can be enabled on Windows using the registry. This is a system-wide setting, and it kicks in immediately once the registry has been updated.

If you save the above as a .reg file you can import it directly into the registry on the test machine. Crash dumps will be written to C:\CrashDumps and the 100 most recent dumps will be stored. See MSDN for the full registry options.

You can open and debug the core dumps that Windows produces in Visual Studio. You will need the pdb files for your application for useful debugging.


You can enable core-dumps in the shell of the program that’s running using ulimit -c unlimited. That enables core dumps with unlimited size (the default is usually 0, so no core dumps are created). Note that this is not a system-wide setting, and you will need to run that in the shell of your program under-test, which might mean putting it inside a service start-up script.

Typically the core file is called just core, or core.process_id.

Core dumps can be debugged with a debugger such as gdb. You’ll need your application to be built with debug symbols (it can still be optimized though), and not stripped of debugging symbols when packaged up in your application’s installer for the core dumps to be useful.


An extra caveat applies on Linux, because where the core file is written is controlled by the file /proc/sys/kernel/core_pattern. Some distributions set this to an error-reporting utility, which may simply ignore core files produced by applications (like your own) that aren’t part of the Linux distribution itself. This can be frustrating if you’re not aware of it, only to discover that despite setting ulimit you didn’t get core dumps when your program crashed.

You can modify the core_pattern file yourself to specify your own pattern.

For example, the following command (assuming your system uses sudo, otherwise remove sudo and run as root) can be invoked to change the system-wide setting for core files:

echo 'core.%e.%p' | sudo tee /proc/sys/kernel/core_pattern

%e is the executable name, and %p is the process id (pid). The full list of supported specifiers for the core filename is documented in man core.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someonePrint this page

Comments are closed