6

I am currently maintaining a WinForms application that listens to the Application.ThreadException event to trap unhandled exceptions on GUI threads.

Now things have been working as expected until recently. But lately, this event is no longer being raised appropriately on some production boxes; the app skips the handler and just crashes when there is an unhandled exception on a GUI thread. Strangely, I am able to reproduce this on my (new) dev box, but there are some machines on which the event is in fact being raised correctly.

I am able to make the behaviour consistent by explicitly setting the policy like this:

Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);

But I am curious to know what controls the default policy. MSDN makes vague allusions to an "application configuration file", but there is no such policy-setting in our app.config or any other configuration file that I know of.

What is causing this inconsistent behaviour?

Ani
  • 111,048
  • 26
  • 262
  • 307

2 Answers2

1

There's only one that I can think of. The exception handling logic is aware whether or not a debugger is attached. That matters when the default UnhandledExceptionMode.Automatic is in effect. When a debugger is attached, the Winforms message loop does not try to catch exceptions. Which is fairly important, it would make debugging exceptions rather difficult. The debugger only steps in and displays the Exception Assistant when an exception is unhandled.

Using UnhandledExceptionMode.CatchException is okay, it makes exception handling consistent. In other words, it will behave on your dev machine exactly the same as it does on your client's machine. But you'll now need Debug + Exceptions, Thrown box to troubleshoot the code. That always makes the debugger stop when the exception is thrown, regardless of whether it is caught or not.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • +1 Thanks. But what could cause the inconsistent behaviour between different client machines? They are both running release builds. – Ani Sep 06 '11 at 16:40
  • Don't underestimate the user's willingness to click Continue in that dialog and not tell you about it. This rarely comes to a good end. – Hans Passant Sep 06 '11 at 17:32
  • We show a dialog when the event is raised, but it is logged anyway; the user doesn't have a say in it. By the way, your related answer here saved me a lot of head-scratching. http://social.msdn.microsoft.com/Forums/en-US/winforms/thread/674d33b5-b199-4f6d-ae79-d32c66d955be/ – Ani Sep 10 '11 at 07:45
  • I think what I'm observing is related to this: http://stackoverflow.com/questions/2876748/exception-in-the-onidle-event-does-not-bubble-up. It's amazing; *three* different answers of yours helped me. – Ani Dec 10 '11 at 06:34
0

I've also begun to experience this. We were trying to debug exceptions that our testers were seeing and couldn't reproduce on our own machines. I turned on the stop-on-exceptions behavior in VS and viola, the exceptions were actually happening. However, if I were to F11 to continue, I'd see that the exceptions are just silently ignored.

I have two machines. One machine is Win 7 64 bit, has VS 2008 and VS 2010 installed, and so .Net 4.0 is installed. The application we're testing is .Net 3.5 and debugged in VS 2008.

The other machine is Win XP 32 bit, plain jane VS 2008 and .Net 3.5.

The Win 7 machine silently ignores. The XP machine loudly complains. I think having .Net 4.0 installed changed some default policy.

I've worked around it by calling 

Application.SetUnhandledExceptionMode( UnhandledExceptionMode.CatchException );
antiduh
  • 11,853
  • 4
  • 43
  • 66