views:

275

answers:

3

I am looking for a better solution than what we currently have to deal with unexpected production errors, without reinventing the wheel.

A larger number of our products are WinForm and WPF applications that are installed at remote sites. Inevitably unexpected errors occur, from NullReferenceExceptions to 'General network errors'. Thus ranging from programmer errors to environment problems.

Currently all these unhandled exceptions are logged using log4net and then emailed back to us for analysis. However we found that sometimes these error 'reports' contain too little information to identify the problem.

In these reports we need information such as:

  1. Application name
  2. Application Version
  3. Workstation
  4. Maybe a screen shot
  5. Exception details
  6. Operating system
  7. Available RAM
  8. Running processes
  9. And so on...

I don't really want to re-invent the wheel by developing this from scratch. Components that are required:

  1. Error collection (details as mentioned above)
  2. Error 'sender' (Queuing required if DB or Internet is unavailable)
  3. Error database
  4. Analysis and reporting of these errors. E.g. 10 most frequent errors or timeouts occur between 4:00PM and 5:00PM. How do the errors compare between version x and y?

Note: We looked at SmartAssembly as a possible solution but although close it didn't quite met our needs and I was hoping to hear what other developers do and if some alternatives exist.

Edit: Thanks for the answers so far. Maybe I wasn't clear in my original question, the problem is not how to catch all unhanded exceptions but rather how to deal with them and to create a reporting engine (analysis) around them.

+5  A: 

I'd suggest Jeff Atwood's article on User Friendly Exception Handling, which does most of what you ask already (Application Info, Screenshot, Exception Details, OS, Logging to text files and Emailing), and contains the source code so you add the extra stuff you need.

Andrew
Thanks this a step in the right direction. I read the article and it provides a solution to part of the problem (collecting errors). As you mentioned it need work for our specific needs but at least it provides a kick start.I am hoping that something else exists for analyzing these errors.
Philip Fourie
+1  A: 

You can attach to the unhandled exception event and log it/hit a webservice/etc.

[STAThread]
static void Main() 
{
    Application.ThreadException += new ThreadExceptionEventHandler(OnUnhandledException);
    Application.Run(new FormStartUp());
}
static void OnUnhandledException(object sender, ThreadExceptionEventArgs t) 
{
    // Log
}

I also found this code snippet using AppDomain instead of ThreadException:

static class EntryPoint {
    [MTAThread]
    static void Main() {
        // Add Global Exception Handler
        AppDomain.CurrentDomain.UnhandledException += 
            new UnhandledExceptionEventHandler(OnUnhandledException);

        Application.Run(new Form1());
    }

    // In CF case only, ALL unhandled exceptions come here
    private static void OnUnhandledException(Object sender, 
        UnhandledExceptionEventArgs e) {
        Exception ex = e.ExceptionObject as Exception;
        if (ex != null) {
            // Can't imagine e.IsTerminating ever being false
            // or e.ExceptionObject not being an Exception
            SomeClass.SomeStaticHandlingMethod(ex, e.IsTerminating);
        }
    }
}

Here is some documentation on it: AppDomain Unhandled Exception

Outside of just handling it yourself, there isn't really a generic way to do this that is reusable, it really needs to be integrated with the interface of the application properly, but you could setup a webservice that takes application name, exception, and all that good stuff and have a centralized point for all your apps.

sontek
A: 

You may want to study the error reporting feature built into JetBrain's Omea Reader. It has a catch-all error-handling component that pops a dialog when an unexpected error occurs. The user can input more details before submitting the problem to JetBrain's public error-collection web service.

They made Omea open source to allow the community to upgrade the .NET 1.1 code base to v2 or 3. http://www.jetbrains.net/confluence/display/OMEA/this+link

icelava