catch all unhandled exeptions does not work for all computers.

[Zytan]

I am using:

Application.Thr eadException += new
System.Threadin g.ThreadExcepti onEventHandler( Application_Thr eadException);

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

[Jon Skeet [C# MVP]]

Zytan <zy**********@g mail.comwrote:

I am using:

Application.Thr eadException += new
System.Threadin g.ThreadExcepti onEventHandler( Application_Thr eadException);

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?

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.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Michael Nemtsev]

Hello Zytan,

What kind of applocation? winform based?
Try to use AppDomain.Curre ntDomain.Unhand ledException 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

ZI am using:
Z>
ZApplication.Th readException += new
ZSystem.Threadi ng.ThreadExcept ionEventHandler (Application_Th readExcept
Zion);
ZBut, my function is not run when an exception is thrown on another
Zcomputer running WinXP SP2, and I have no idea why. Instead, the
ZWindows error report screen appears. Isn't the above supposed to
Zwork no matter what? What am I doing wrong?
Z>
ZZytan
Z>

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

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

Peter
--
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
Short urls & more: http://ittyurl.net


"Zytan" wrote:

I am using:

Application.Thr eadException += new
System.Threadin g.ThreadExcepti onEventHandler( Application_Thr eadException);

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]

Could you post a short but complete program which demonstrates the

problem?

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

[Zytan]

What kind of applocation? winform based?

Yes, a Windows Form.

Try to use AppDomain.Curre ntDomain.Unhand ledException handling

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

[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

Thanks, Peter, I will read this now.

Zytan

[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

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.Thr eadException += new
System.Threadin g.ThreadExcepti onEventHandler( Application_Thr eadException);

Zytan

[=?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=]

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

Thread.GetDomai n().UnhandledEx ception += new
UnhandledExcept ionEventHandler (Application_Un handledExceptio n);

Application.Thr eadException += new ThreadException EventHandler(
Application_Thr eadException );

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


"Zytan" wrote:

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

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.Thr eadException += new
System.Threadin g.ThreadExcepti onEventHandler( Application_Thr eadException);

Zytan

[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.

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