catch all unhandled exeptions does not work for all computers.

[Zytan]

I am using:

Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Appli cation_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

[Jon Skeet [C# MVP]]

Zytan <zy**********@gmail.comwrote:

I am using:

Application.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Appli cation_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?

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

ZI am using:
Z>
ZApplication.ThreadException += new
ZSystem.Threading.ThreadExceptionEventHandler(Appl ication_ThreadExcept
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.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Appli cation_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]

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.CurrentDomain.UnhandledException 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.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Appli cation_ThreadException);

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.GetDomain().UnhandledException += new
UnhandledExceptionEventHandler(Application_Unhandl edException);

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


"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.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Appli cation_ThreadException);

Zytan

[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_Unhandl edException);

Application.ThreadException += new ThreadExceptionEventHandler(
Application_ThreadException );

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.

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.

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

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

[Zytan]

Thread.GetDomain().UnhandledException += new

UnhandledExceptionEventHandler(Application_Unhandl edException);

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

[Bruce Wood]

On May 9, 12:52 pm, Zytan <[e-mail]:

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_Unhandl edException);

Application.ThreadException += new ThreadExceptionEventHandler(
Application_ThreadException );

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.

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.

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.

[Bruce Wood]

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.

On May 9, 4:23 am, Peter Bromberg [C# MVP]
<[e-mail]:

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.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Appli cation_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

[Bruce Wood]

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.

On May 9, 4:23 am, Peter Bromberg [C# MVP]
<[e-mail]:

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.ThreadException += new
System.Threading.ThreadExceptionEventHandler(Appli cation_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]

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 += ...
}

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

[Bruce Wood]

On May 10, 8:01 am, Zytan <[e-mail]:

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 += ...
}

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.

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.

[Zytan]

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.

Right, thanks for your help, Bruce!

Zytan