views:

66

answers:

3

I have an unhandled exception handler. It shows a nice GUI and allows users to send an error report. Users can even leave their name and phone number and things, and our support department calls them back. Works well, looks good, makes customers less angry. In theory, anyway.

The problem is that my application uses background threads, and the threads don't seem to care if an exception was thrown on, say, the GUI thread (which makes sense), and just continue their work. That eventually results in a WER dialog poping up if the user lets my custom exception handler window stay open long enough, making it look like the error handler itself crashed.

I don't have access to the thread objects in the scope of the exception handler, so I can't suspend them. Making the thread objects globally accessible is not a solution either. My workaround for now is to use something like Globals.Crashed = true; in my exception handler, and to have my thread methods check that property at every loop iteration. Not perfect, but it minimizes the damage.

Does anyone know a less-hacky method? Is my approach wrong? Do I have to do it like WER does and launch an external program that suspends the main program and shows the error UI?

A: 

You could track all your threads in a global Collection object, so that when your handler executes, it could simply iterate through the collection object and abort the threads there.

Russ
I think there was a discussion in the last week or so that touched on this subject. Let me see if I can find that link...Ok, here it is: http://stackoverflow.com/questions/3480451/time-limiting-a-method-in-c
FrustratedWithFormsDesigner
+4  A: 

If you have an unhandled, unknown exception, you can assume that ANYTHING has happend and that your program might fail to do even the most simple thing. Consider e.g. the case that it has consumed all available memory - then you won't be able to send the error report either, because it probably requires memory to be allocated.

A good approach is to write a separate small application that just does the error reporting. That application can pick up the details to report from a file. That way your unknown exception handler would:

  • Dump the info to a file in the temp directory.
  • Start the error reporting app with the file name as an argument.
  • Terminate the failing process, before it does something stupid.

The temp file should be removed by the error reporting app.

Anders Abel
That sounds like the best approach. Thanks.
Anonymous Coward
A: 

Take a look at the code in this question, Suspend Process in C#, you'll need to tweak it so as to not suspend your GUI thread and any that aren't background ones you've started, but it should do the trick.

The better option, however, is to try and launch your error report GUI as a separate process, passing any required information to it, and then kill the original process from your unhandled exception handler, rather than allowing anything to run in a potentially corrupt state.

Rob