A crash report collects, synthesizes and presents data that helps developers understand, diagnose, and fix the underlying problem.
On this page we break down a crash report to give you detailed understanding of its contents.Crash Name and Stack Key
The top left of a crash report provides critical information for labeling and sorting crashes. You can identify the crash by its unique crash ID. Next to the crash ID is an icon that indicates on what platform the crash occurred. Finally, to the right of the crash ID, you can use the containing Stack Key link to navigate to the group of all similar crashes.
The next and previous buttons allow you to quickly navigate between crashes and the reprocess button allows you to re-analyze a crash report. You might reprocess after you may have made configuration changes that affect the analysis, such as adding an additional symbol server, configuring a common symbol store, or setting the Electron symbols option via the Options page. Or, if BugSplat was unable to analyze your crash due to a transient problem, the reprocess button should resolve the issue.
This component contains a summary of the crash including information on the user that was affected, the exception showing the reason for the crash, when the crash occured, as well as a variety of other self-explanatory data.
After determining what course you should take with your crash, you can use the tools on the right-hand side to leave a comment for yourself or a team member, or to create a defect in your bug tracking system.
BugSplat works with most popular bug tracker/defect tracker tools. Find our full list here. If you don't see your tool let us know and we'll add it for you.
These six tabs to give additional information about the crash. The information is similar to what you would find if you managed to capture the crash in a debugger.
The Active Thread tab shows the thread ID of the thread that crashed as well as the complete stack trace at crash time. The top of this stack trace is the line of code that caused the exception. Next to each row of the call stack is a carrot that expands the row to give you additional details. Expanding the row will display a button that allows you to group your call stack at that level. Additionally, for Windows Native crashes, expanding the row will reveal the value of function arguments and local variables.
If the crash is significant enough to fix, or you need to do more work to determine how important it is, you’ll use these six tabs to get more information about what caused the crash to occur.
The Debugger Output tab shows the output from the debuggers running on BugSplat's backend. This tab contains information that could be used, for example, to help you diagnose why your crash report is missing symbolic information. Debugger Ouput information is available for Windows Native, .NET Framework, Breakpad, Crashpad and OS X crashes only.
The Other Threads tab shows what else was going on when the application crashed. Other thread information is available for Windows Native, .NET Framework, Breakpad, Crashpad and OS X crashes only.
The Registers tab shows the values of various system register at crash time. Registers information is available for Windows Native crashes only.
The Modules tab shows information on which modules were loaded at runtime. Modules information is available for Windows Native, .NET Framework, Breakpad, Crashpad and OS X crashes only.
The Debugger Output tab shows the standard output from the debuggers running on BugSplat's backend. This tab contains information that will help you diagnose why your crash report is missing stack information. Debugger Ouput information is available for Windows Native, .NET Framework, Breakpad, Crashpad and OS X crashes only.
The Attachments tab lists all the files that were sent along with your crash report.
The above example is from a Windows Native sample crash, but BugSplat works with a wide variety of other platforms. To learn more about what type of crash data you can expect from each please view our Platforms page.