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 <(E-Mail Removed)> wrote:
> 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?

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 - <(E-Mail Removed)>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

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>

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(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
>
>

> 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

> 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

> 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

> 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(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




"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(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 );

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