catch all unhandled exeptions does not work for all computers.

  • Thread starter Thread starter Zytan
  • Start date Start date
Z

Zytan

I am using:

Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Application_ThreadException);

But, my function is not run when an exception is thrown on another
computer running WinXP SP2, and I have no idea why. Instead, the
Windows error report screen appears. Isn't the above supposed to work
no matter what? What am I doing wrong?

Zytan
 
Zytan said:
I am using:

Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Application_ThreadException);

But, my function is not run when an exception is thrown on another
computer running WinXP SP2, and I have no idea why. Instead, the
Windows error report screen appears. Isn't the above supposed to work
no matter what? What am I doing wrong?
Click to expand...

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.
 
Hello Zytan,

What kind of applocation? winform based?
Try to use AppDomain.CurrentDomain.UnhandledException handling

---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

Z> I am using:
Z>
Z> Application.ThreadException += new
Z> System.Threading.ThreadExceptionEventHandler(Application_ThreadExcept
Z> ion);
Z> But, my function is not run when an exception is thrown on another
Z> computer running WinXP SP2, and I have no idea why. Instead, the
Z> Windows error report screen appears. Isn't the above supposed to
Z> work no matter what? What am I doing wrong?
Z>
Z> Zytan
Z>
 
Could you post a short but complete program which demonstrates the
problem?
Click to expand...

No, I cannot, since I don't have access to the machines on which my
code does not work. I think the single line of code that I provided
is all that is required to make this work, and for some reason that
line of code does not do anything on certain WinXP machines. I am
dumbfounded that the results vary.

Zytan
 
What kind of applocation? winform based?

Yes, a Windows Form.
Try to use AppDomain.CurrentDomain.UnhandledException handling
Click to expand...

Michael, I tried this, and rejected this for two reasons:
1. When in the debugger, this catch will run its own code before the
debugger has a chance to catch the exception itself. It gets in the
debugger's way.
2. When in release, Windows catches the error first. This is the most
important job for it to do, and it doesn't do it.

Zytan
 
Here is a short article that summarizes a lot of this, including Registry
setting that controls the JIT Debugger Windows Error screen popup:

http://www.eggheadcafe.com/articles/20051205.asp
Click to expand...

Unfortunately, this articles just enumerates all ways to catch
exceptions. It doesn't summarize anything else, like about how they
work, which one is better, in which situations one is better, which
one could be used in deployment, etc. All it is are methods to help
the developer catch the problem on her own machine.

So, I'm still at square one, trying to determine why the following
code 'fires' on some WinXP machines (mine), but not on others (that I
unfortunately can't get my hands on, at the moment). It's hard to
beta test something that is not consistent.

Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Application_ThreadException);

Zytan
 
Well, as the other posters (and the article) indicated, there are only two
handlers to catch an unhandled exception event:

Thread.GetDomain().UnhandledException += new
UnhandledExceptionEventHandler(Application_UnhandledException);

Application.ThreadException += new ThreadExceptionEventHandler(
Application_ThreadException );

if you have them both wired up correctly in your application, and there is
an unhandled exception, then depending on whether it occured on the main
thread or elsewhere, one of these is going to sqwawk.

Bear in mind these are EVENT handlers, not "exception" handlers. Once you
have an unhandled exception, your deal is gone - these are just there to give
you a last chance to perform cleanup, log the event, etc.
Peter

--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net
 
Well, as the other posters (and the article) indicated, there are only two
handlers to catch an unhandled exception event:

Thread.GetDomain().UnhandledException += new
UnhandledExceptionEventHandler(Application_UnhandledException);

Application.ThreadException += new ThreadExceptionEventHandler(
Application_ThreadException );
Click to expand...

Yes, and I've fully tested them both. On my development machine,
WinXP, Application.ThreadException works correctly in debug and
release, and the other one doesn't wory correctly in either. By
'correctly', I mean I want the debugger to grab the exception first,
and in release mode, I want my code to grab the exception before
Windows does.

But, for some reason, this behaviour is not consistent. I have no
idea why.
if you have them both wired up correctly in your application, and there is
an unhandled exception, then depending on whether it occured on the main
thread or elsewhere, one of these is going to sqwawk.
Click to expand...

Indeed, I could hook them both up, and I have tried that, and it
pretty much guarantees, perhaps on all computers, that the code will
be run. Unfortunately, this also means you can't debug the exception
on the spot, that's why I avoided it. Maybe I'll just have to bite
the bullet, and lose my debugger's ability to grab exceptions, and let
my code always catch it, if that's what I need to do to ensure other
computers in a release build will catch them, as well.
Bear in mind these are EVENT handlers, not "exception" handlers. Once you
have an unhandled exception, your deal is gone - these are just there to give
you a last chance to perform cleanup, log the event, etc.
Click to expand...

Yes, of course, I just use this to log the error, and email the crash
report.

Zytan
 
Maybe I'll just have to bite
the bullet, and lose my debugger's ability to grab exceptions, and let
my code always catch it, if that's what I need to do to ensure other
computers in a release build will catch them, as well.
Click to expand...

Hm, I'll just NOT run the one that doesn't work if I'm in debug mode.
That way the release mode can catch everything and anything it wants,
and it should. And in debug mode, hey, I don't even need any of these
things running, actually, if the debugger is there, since it always
catches everything (right?).

Zytan
 
Thread.GetDomain().UnhandledException += new
UnhandledExceptionEventHandler(Application_UnhandledException);
Click to expand...

It is difficult to test this, since on my machine, JIT catches this.
What would happen on another non-development machine, without JIT?

Also, how can you get the exception information from
UnhandledExceptionEventArgs? It has a ExceptionObject, but it's
'object', not 'Exception'. Can it be typecast into Exception? Well,
it can, but would that work?

I can't test this out since I can't even get my code to run without
the JIT jumping in first!

Zytan
 
Yes, and I've fully tested them both. On my development machine,
WinXP, Application.ThreadException works correctly in debug and
release, and the other one doesn't wory correctly in either. By
'correctly', I mean I want the debugger to grab the exception first,
and in release mode, I want my code to grab the exception before
Windows does.

But, for some reason, this behaviour is not consistent. I have no
idea why.


Indeed, I could hook them both up, and I have tried that, and it
pretty much guarantees, perhaps on all computers, that the code will
be run. Unfortunately, this also means you can't debug the exception
on the spot, that's why I avoided it. Maybe I'll just have to bite
the bullet, and lose my debugger's ability to grab exceptions, and let
my code always catch it, if that's what I need to do to ensure other
computers in a release build will catch them, as well.
Click to expand...

Well, there are ways to avoid the problem with you're running under
the debugger.

For example, I do this:

if (!System.Diagnostics.Debugger.IsAttached)
{
Application.ThreadException += ...
AppDomain.CurrentDomain.UnhandedException += ...
}

That way I don't hook up the exception handlers when I'm running under
the debugger.
 
Interesting article, Peter. The only problem is that my attempts to
print it have all met with mixed success (multiple blank pages
followed by just a part of the article). Probably something to do with
the way the site formats its articles.
 
Peter,

What *I* really want to do is set up a machine so that my applications
NEVER pop a dialog when they crash.

For some odd reason on one of our production machines, if one of
my .NET exes dies, it pops the "Debug or cancel" dialog.
Unfortunately, this machine runs batch jobs, and the dialog hangs the
batch stream for the night. The guy in charge of it is not amused.

Is there a way to force that stupid dialog off? I'm already trapping
and logging the errors. I have no need of the dialog.
 
Well, there are ways to avoid the problem with you're running under
the debugger.

For example, I do this:

if (!System.Diagnostics.Debugger.IsAttached)
{
Application.ThreadException += ...
AppDomain.CurrentDomain.UnhandedException += ...
}
Click to expand...

I just use #if !DEBUG ... #endif. But, I suppose it is the debugger
that I'm concerned with, so I should just check that, as you do, and
be certain.

Thanks!

Zytan
 
I just use #if !DEBUG ... #endif. But, I suppose it is the debugger
that I'm concerned with, so I should just check that, as you do, and
be certain.
Click to expand...

Yes. #if !DEBUG tests to see if the program was _compiled_ for debug
or release.

System.Diagnostics.Debugger.IsAttached checks to see if the program is
actually running under the debugger. It depends upon what behaviour
you want. I occasionally put debug versions on our test servers for
users to play with, and in that environment I want errors trapped and
logged, even though the program was compiled for debug.
 
Yes. #if !DEBUG tests to see if the program was _compiled_ for debug
or release.

System.Diagnostics.Debugger.IsAttached checks to see if the program is
actually running under the debugger. It depends upon what behaviour
you want. I occasionally put debug versions on our test servers for
users to play with, and in that environment I want errors trapped and
logged, even though the program was compiled for debug.
Click to expand...

Right, thanks for your help, Bruce!

Zytan
 
Back
Top