This all makes sense and is logical, but there is a lot going on here. To build and implement an error capturing framework yourself would be a significant undertaking, perhaps more involved than the application it’s supposed to monitor. As this scenario is common to all software projects its not surprising that there is a raft of products designed to help developers integrate exception capture and bug tracking with development workflow.  

Products like Raygun will collect exception data from your application, help you prioritize and diagnose the issue, and then link to a development workflow system like Jira or Zendesk. 

As it happens, Azure’s relatively new App Centre has just the features you need to capture and analyze exception data with very little effort.

Setting up an app for error tracking in App Center is easy. Navigate to appcenter.ms. Click Add new app. In the Add new app dialog give your app a name and select the Release Type. Release types are what you might expect. Alpha, beta, enterprise, production and store, or you can create your own custom release name. Then select the OS and platform. There is a wide range of OS and platform support, although there is currently no support for JavaScript based SPA apps which does seem like quite an oversight. There is a link at the bottom of the dialog to tell Microsoft if you are using another platform, and I would encourage you to do so.

Integrating basic error detection into your application is quick and simple. Start by installing the Microsoft AppCenter Crashes package into your project. Add the using statement to your source code. Before you can use AppCenter Crashes you must start the SDK with AppCenter start. You need to supply the app secret you obtained when registering your application with App Center, and the type of services you want to use. In this case, that parameter will be typeof crashes. We are going to record exceptions and crashes, that is an exception that causes the application to crash, as oppose to a caught exception. 

Looking first at a typical try catch scenario, we can call the Crashes TrackError method of the SDK within the catch block. TrackError takes an exception as its parameter. The Crashes SDK also has callbacks that can be used for processing error reports from a previously crashed session or getting user feedback from the UI. The callbacks need to be set up before calling App Center start. Conversely you need to start the App Center SDK before calling any of its methods.

This ErrorInitialization function illustrates how you might put these features together on app startup. Firstly, we setup our callback saying we only want to process an error report if it isn’t a blue screen of death. Next, we start the App Center. Then we find out if the application crashed out the last time it ran. If it did, we get the crash report from the last session and display a message to the user.  This last session functionality is very useful as it allows us to easily figure out if the last session went badly and let the user know, that we know all is not well and action will be taken to remedy the problem.

As a side note, Microsoft say, “By default, an unhandled exception in a WinForms application does not trigger a crash (the application does not exit) if the debugger is not attached.” One way around this situation is to call Application SetUnhandledExceptionMode to ThrowException. This will get Winform applications to correctly display crashes in App Center..

User privacy is another factor to keep in mind and the Crashes SDK does provide a call back feature, ShouldAwaitUserConfirmation, where you can ask the user to confirm whether or not they consent to sending error data. This simple example does not cater for the AlwaysSend option that is available with the NotifyUserConfirmation method. You also have the ability to attach files to your error report. This would be useful for sending detailed application state in data driven or highly configurable apps. At the moment the maximum size of attachments per error report is 7 megabytes.

In your project’s App Center go to diagnostics to see a dashboard of all issues. This is where you see the crashes and exceptions separated into groups. A group is all the instances of a particular crash or exceptions. I did find it interesting that the grouping is based on the location within the code as a whole rather than the location within a function as identified by it’s signature. The Main_FORM Tables_LB_Click crash is exactly the same exception, but the one that occurred most recently on line 153, was after I added the ErrorInitialization function above it. Clicking on a group will take through to a detail view.

Here we can see the stack trace plus the number of times the crash has occurred and the number of impacted users. What’s particularly useful for mobile developers is a breakdown of devices and OSes that the crash has occurred on. On the top right you can change the status of the crash group from open to closed or ignored. Clicking on the Reports tab will display all the instances of the crash.

Clicking on a report or instance will display additional information like country and language, and also how far into the session or after app startup did the crash occur under the heading Crashed after. The threads tab shows the stack trace data, while attachments will display any data files that have been uploaded with the error report. Events are analytic events that were recorded just prior to the crash – we’ll have a look at those later.

 

Ideally, we want to be notified A.S.A.P when our app has crashed. This can be easily set up by going into settings and selecting email notifications. Then under crashes select when you want to be emailed about a crash event. Your choices are immediately, daily or never.  On the right is an example of crash group email. It has basic information with a link to the crash group.