Skip to main content


Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Getting useful information out of crash reports (Read 23743 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Getting useful information out of crash reports

Preparing your component for a public release

You are not special. You are not a beautiful or unique snowflake. You're the same decaying organic matter as everything else. - Tyler Durden

Your components will crash. Not necessarily because you have done something wrong. Submitted crash reports will demonstrate failure scenarios you would have no idea about otherwise, and additionally if your code is popular enough, you'll get your own share of reports triggered by broken hardware.
To keep the development process as comfortable as possible for you (less effort required to analyze crash reports) and your userbase (faster bug fixes), you should take appropriate steps before releasing your component to the general public.

1. Enable debug information in release builds of your components.
Having matching debug information files (.pdb) will greatly increase the usefulness of minidump (.dmp) files included with crash reports, essentially taking you straight to the code line where the problem manifested itself, instead of having you go through assembly code.
This will not bloat size of your binaries, only increase it by a few kilobytes, including a reference to your debug information file name. You do not need to distribute the large .pdb files with your component.
You need to enable debug information in both C/C++ / Debug Information Format and Linker / Debugging / Generate Debug Info.
You might want to generate a few test crashes yourself to see if opening the created minidump takes you straight to the crashing code line.

2. Archive binaries and PDB files for every version you release publicly so submitted crash reports can be easily analyzed.

3. Use call path tracking macros around critical function calls.

More useful information on minidump file usage:

My component has been released, now what?

If your component appears on the online troubleshooter, this means that crash reports can be made available to you on request. Contact me or another forum staff member to obtain them. In some cases you will be contacted preemptively before the component is put on the troubleshooter.
Microsoft Windows: We can't script here, this is bat country.