Welcome Guest ( Log In | Register )

> foobar2000 Development Forum Rules

This forum is for developer discussions only. If you have a problem / bug report / idea / feature request that isn't related to foobar2000 SDK, post it in an appropiate forum instead - tech support questions go to support forum, everything else goes to general forum.
All non-developer posts on this forum will be removed. Continued abuse of this forum will result in admin actions (warnings, account suspension).

Closed TopicStart new topic
Getting useful information out of crash reports, Recommended steps before releasing your first component
post Nov 19 2009, 14:15
Post #1

foobar2000 developer

Group: Admin
Posts: 3359
Joined: 30-September 01
Member No.: 84

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: http://www.codeproject.com/KB/debug/postmo...tandalone1.aspx

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.
Go to the top of the page
+Quote Post

Closed TopicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:


RSS Lo-Fi Version Time is now: 2nd December 2015 - 04:26