Diving into ASP.NET error tracking

| 5 min. (876 words)

It’s a fact of life that the software you create will always have bugs; a mark of a professional developer is one who recognizes this and takes steps to mitigate the disruption they cause. Modern software is deployed to a variety of environments, whether the code is destined for the desktop, server or mobile devices errors will occur and must be dealt with. Some environments are easier to deal with than others – for instance a user can email you steps to reproduce a bug in a desktop application, or they can report a server error when using a website, which you can diagnose by checking the logs.

This however puts the onus on the user to report the issue, which many will not bother doing (they might just give up and turn to a competitor). And once a mobile app’s released it will be used on a large range of devices which you most likely won’t have the opportunity to test on. In this post, I’ll be discussing the various options for tracking live errors in mobile and server applications that use the .NET framework, some of which result in a better workflow and less buggy, more pleasing software for the end user.

ASP.NET network applications

Firstly, looking at web sites and applications: for ASP.NET on IIS, locally you’ve got the Yellow Screen of Death while developing, but that certainly won’t do once the site’s deployed. For production servers, checking out the failed request and other log files would give an indication of where and when a user encountered an HTTP 500 error. But this assumes that you have remote access to the server, which is not necessarily a given. Even if you do, trawling through thousands of log files is a daunting, almost impossible task when trying to pinpoint a user’s error. You’re also not notified when an error occurs, making this a fairly primitive solution.

You might next consider a logging framework like log4net, which allows you to pipe out exceptions in catch blocks or in the Application_Error() event handler. This has the same downsides as the above method, in that you need remote access to view the resulting logs (unless you want to implement your own email solution from scratch).

A more complete library for ASP.NET is ELMAH, which in addition to logging unhandled exceptions does provide email notifications when one occurs, as well as a web page to view the entire exception log. You can view details for one exception occurrence here, including the stack trace, so this solution fulfils the basic requirements by allowing you to debug your production site remotely. One major downside to ELMAH is that each exception occurrence is listed as a new entry, even though it’s guaranteed that many will be duplicate notices of the same bug (potentially thousands). You’re still going to drown in data using this library.

Raygun’s solution to this problem is to provide a service that accepts exception notifications and intelligently groups them depending on their content. For instance, a 404 controller bug won’t produce hundreds of different errors if the messages are all different (i.e. different query strings); instead they’ll be grouped into one error containing the different instances. Drilling down into that error group, you can compare their data which can give you insight into the root cause. Raygun also sends emails when a new exception occurs, and sends follow-up mails if it keeps occurring. It also provides daily digest emails with a summary of the day’s activity, so you can keep an eye on the error trend over time.

Mobiles apps

Building apps for mobile devices using .NET is pretty great these days – whether native Windows Phone, WinRT tablets or using Xamarin to target iOS/Android. Unlike a server application when your app crashes on a user’s device the logs and stack trace are almost certainly not available, and this becomes a concern due to the large range of hardware on which your app will run now and in the future.

Raygun solves this by having the .NET provider, which you add to your code, automatically catch and send all exceptions to the API service in real time. All users and all devices transmit their exceptions without you or your users lifting a finger. Forcing your users to take the time to file bug reports ensures that many will be driven away unsatisfied, while having your transmit its own exceptions is painless.

Mobile devices also have unique operating environments, in that network access is not always guaranteed. We solve this by having the client provider cache the messages locally until the device regains internet access, providing a seamless experience for the users and ensuring you don’t miss out on any notifications.

Use an error tracking service

As discussed, traditional methods of discovering errors such as local log files are too cumbersome or even inapplicable for server and mobile applications. Only a service like Raygun can provide intelligent grouping of similar errors to prevent you drowning in data. ELMAH comes close, but it will flood your inbox with notifications for the same error, and can’t provide grouping or summary emails. Interested in checking out Raygun? There’s a 30-day free trial available here. Got any questions or comments? Post them below!