Hosted exception collection for .NET applications made easy –

I own a company, Tiger Computer Services Ltd, which is an Independent Software Vendor (ISV) providing .NET software solutions to clients in the London area.

One of the most significant considerations when running a small ISV is the cost of supporting software in the field. For some clients, support is not a billable item, especially if the fault is within the software we have provided. This means that every time the telephone rings, we bleed money, and if we have to actually go on site to resolve an issue it gets worse.

Whether the software solution is ‘packaged’ or is a custom solution, all our clients run the software on their own equipment at their own premises.  We have never asked for VPN access into their network.  We take the view that if you cannot easily VPN into a system you have a real incentive to write reliable software that works first time and doesn’t need continuous intervention.

However, although all the clients can be reached within about one hour by public transport, an on-site visit is bad for many reasons;

  1. It costs money; either to ourselves or to the client (the latter is even worse if someone has to approve the cost in advance of the visit)
  2. It takes time, which can lead to more issues; i.e. data corruption through continued use of the software
  3. It is highly disruptive of work being undertaken for other clients

Exception handling is a good thing

This may sound obvious, but however good your programming is, it’ll generate exceptions.  It is impossible to account for all eventualities and you need to be ready to handle them and log the state of the system when they occurred.

The solutions we deliver are generally a combination of ASP.NET web applications, Windows Services (Windows Forms applications with no user interface) and usually with some database server in the background (SQL Server, MySQL or Oracle).  Our exception handling is wrapped up in a set of reporting libraries whose history dates back to before Visual Basic 6.

The reporting libraries were overhauled in the transfer to C#, and they provide a simple method for logging messages and exceptions simultaneously to the Windows Event Log, text based log file, SMTP e-mail and interactive dialogs (for Windows Forms applications with a user interface).

The libraries consist of a central reporting engine, into which various reporters are plugged and these handle all the various methods for recording exceptions.  One call to the reporting engine to display a message or exception calls all the reporters in turn.  This allows new methods of reporting exceptions to be added quickly, and for various methods to be turned off as required (such as disabling writing to the Event Log on shared hosting providers).

Whether you use the Microsoft application block, log4net or some home grown exception handling, the biggest issue is getting access to the log files or event log messages once an exception has occurred.

Without remote access, we rely on the client IT team to either take the text log file, or dump the Event Logs to a CSV file, and e-mail the file to us. Of course, this assumes that the client is already aware they have a problem, which means it has very likely started to affect their use of the application.

Proactive exception handling

In an ideal world you would receive notification automatically about any exceptions in your applications, without requiring intervention from the client.

Nothing impresses a client more than when you phone them to tell them they have an issue, and that you have already got a solution which they can implement to fix it.

Although our reporting libraries do include an SMTP e-mail reporter which can provide some of this proactive functionality it is not always possible to persuade clients that their SMTP gateway or firewall should be ‘tweaked’ to allow support e-mails out of the building.


Earlier this year I was kindly invited into a beta program for a ‘hosted exception collection’ service called Exceptioneer run by the good chaps at Pixel Programming, Phil Winstanley (a Microsoft MVP, no less) and Chris Gaskell. 

These guys write .NET applications for a living and had already created their own centralised exception collection system for their own applications, solving the issues encountered when creating this type of solution.  Realising they had something well worth sharing, they turned their system into a packaged, hosted service for other developers and Exceptioneer was born.

.NET support

Exceptioneer supports ASP.NET, Windows Forms and JavaScript (although I have yet to use the JavaScript exception hander).

Integration in an ASP.NET application is simple; reference the Exceptioneer web client assembly and add a few lines in the Web.Config and it will be reporting unhandled exceptions right away. 

For Windows Forms, you need to reference a windows form assembly and integrate the API into whatever exception handling system you are already using.  We had it integrated with our reporting engine within an hour or so.

What does Exceptioneer provide?

The management interface of Exceptioneer provides a very clean web interface, where you can view all your registered projects (limited to three in the free service), and drill down into the various exceptions which might have occurred, when the last occurred and what application generate the exception.

Repeated exceptions are intelligently grouped with drill down for further detail, including stack traces and full source code from the PDB file if you are testing a debug compilation.  You can identify the exact line causing the issue, and 75% of the time it is possible to identify the underlying cause without even starting up Visual Studio to view the source code.

Exceptioneer provides e-mail notifications, and if you are a Twitter user, Exceptioneer can even send direct messages when new exceptions occur, which tends to catch the eye even quicker than e-mails.

... and it works

Since integrating Exceptioneer with a new system deployed in September, it has proved invaluable for resolving issues (related to user input which was not being verified correctly) which would have come close to an on-site visit to identify exactly what was happening.

Even better, on most occasions we phone the client first to inform them that they had the problem (which occurred more than once) and the IT support guys were able to fix the problem before the end user actually realised something had gone wrong.

Try it yourself

Now the beta program has been completed, the service has been opened for everyone.  I recommend heading over to and registering for a free account, and giving it a spin in your own projects.

Print | posted on Friday, November 20, 2009 1:32 AM

Comments on this post

# re: Hosted exception collection for .NET applications made easy –

Requesting Gravatar...
I cant think why anyone would want to do this, seems to me to be trying to solve a problem that doesnt exist - I dont want exception info for a site held elsewhere - that's an additional security risk is it not?
Left by Gregor Suttie on Nov 21, 2009 8:17 AM

# re: Hosted exception collection for .NET applications made easy –

Requesting Gravatar...

I'm sorry you don't think that a hosted solution serves a purpose. We have certainly found it useful during our beta testing of the system. As I detailed, we don't have remote access to client sites, so collecting exceptions can be an issue. We also find it advantageous to be notified immediately rather than waiting for a client to get in touch with us.

The issue of a security risk does raise a valid point, as there would be in any situation where there is communication between a client system and a third party. We are very careful that our exception messages have no data payload as this is handled byin an accompanying Event Log 'information' message which is not logged by Exceptioneer (as it is not an exception). I don't regard a stack trace with no data as representing a security risk.

We have also put a request in with the developers to allow configuration of any additional data; both for individual installations or at a global level within the management interface. This will be essential at some clients, where server, application and session variables may hold sensitive information.
Left by Liam Westley on Nov 23, 2009 9:53 AM

Your comment:

 (will show your gravatar)