Why Crash Reporting?
Crash reporting allows us to easily find, fix, and track crashes affecting our users. Crash Reporting Tools like Bugsplat are thought of as guard dogs always ready to let you know if something goes wrong so you can identify the culprit and contain it. They also offer critical data and analysis about the number of crashes, including which devices were affected most and so on.
About Bugsplat
BugSplat enables teams to build seriously good software by streamlining their support and development process with stellar crash reporting data.
Benefits
- Simple Setup and Configuration – Integrating BugSplat into your application is simple and straightforward for your development team
- Advanced-Data for Debugging -BugSplat orders crashes by their frequency and severity.
- Complements Your Team’s Workflow – integrates with your team’s favorite bug-tracking tools and other applications
- Multiplatform support – C++, Java, .Net, Breakpad, Unity, and Osx are supported.
- Easily Integrate with your tools -Slack, JIRA, BugZilla, DevTrack, Fogbugz, Axosoft
- Trusted by Companies like Newforma, Atlassian, Quicken, Nitro, Prezi, Tripwire and other thousands of developers.
Simple Integration
Integrating BugSplat crash reporting with your .NET applications is easy! Register, Login and Integrate BugSplat SDK
Enabling your application with BugSplat technology:
In a few simple steps, your .NET application can be modified to provide full debug information on the BugSplat website when it crashes.
- Add a reference to “BugSplatDotNet.Dll”.
- Add a call to BugSplat.CrashReporter.Init and add the BugSplat exception handlers for the appropriate set of system exceptions. As shown in the myDotNetCrasher sample app, this takes just a few lines of code.
The initialization call requires three parameters: the BugSplat database, application name, and version. You supply the application name and version. The BugSplat database is created and selected on the Databases. Typically, you will create a new database for each major release of your product.
- Add .exe, BugSplatDotNet.dll, and BugSplatRC.dll to your application’s installer
- Edit .dll with Visual Studio if you wish to change the banner displayed when your application crashes.
- Add symbolic debug information to your release build.
Note: To get symbolic stack reports, debug information (PDB files) needs to be uploaded to the BugSplat website along with your application’s executable files. Modify your build settings so that symbol files are created for Release builds, e.g.,
Remember that after each build you should upload the new executable and PDB files. The myDotNetCrasher sample app uses a Visual Studio post-build event to automate this step.
- Finally, note that the Visual Studio debugger’s hosting process can interfere with BugSplat’s ability to resolve symbols; it should be disabled in your project’s debug settings when submitting crash reports that occur while debugging.
Test your application by forcing a crash, and then verify that crashes are posted and symbol names are resolved.
Some Screenshots from Bugsplat:
