CLR Exception / Unhandled Exception

[amyl]

I have an application whose main function is encapsulated in encased
in a try/catch block catching Exception. My application has crashed
on several occasions with a CLR exception.

CLR exception - code e0434f4d (!!! second chance !!!)

So far I have been unable to create a test case that reproduces the
crash. My application makes extensive use of asynchronous programming
using waithandles.

Are there exceptions that "Exception" simply does not catch?

Amy.

 

[José Joye]

Are you using .NET 2.0?

- José

 

[Joel Askey]

Hi Amy,

Assuming this is a Console or WInforms app, can you post your Main()
function?

Another tip is to run Visual Studio with Debug / Exceptions (you may have to
add this menu option manually) set to break whenever a CLR exception is
thrown (default is to try handling the exception without breaking).

I have a try/catch around my Application.Run call in Main(), and it usually
catches everything that isn't handled elsewhere.

I suspect there is a piece of code somewhere that doesn't have try/catch set
up.

 

[AMDRIT]

for me, in VB.net, I listen for the application's thread exception to handle
unhandled exceptions. Perhaps, this will help you drill into your exception
issue.

 

[Nicholas Paldino [.NET/C# MVP]]

Amy,

In this case, yes, if you throw an exception on another thread, then a
try/catch block in a piece of code that is in a stack on another thread
isn't going to catch the exception.

If you want a generic catch-all for all threads in your app domain, you
might want to check out the static UnhandledException event on the AppDomain
class.

 

[Peter Duniho]

[...]
If you want a generic catch-all for all threads in your app domain,
you
might want to check out the static UnhandledException event on the
AppDomain
class.

Noting, of course, that that doesn't actually handle the exception. It
just provides a way to know the exception occurred as the unhandled
exception causes the application to exit.

To the OP: if you wrote the code that's running in the other thread, then
to handle exceptions in those threads you can wrap _that_ code with a
separate exception handler (try/catch), just as you've done for the main
thread.

Pete

 

[amyl]

This makes sense than and I bet this is what's happening since from
what I can gather from the memory dump is happening in an asynchronous
call.

Thanks,
Darrell

Amy,

In this case, yes, if you throw an exception on another thread, then a
try/catch block in a piece of code that is in a stack on another thread
isn't going to catch the exception.

If you want a generic catch-all for all threads in your app domain, you
might want to check out the static UnhandledException event on the AppDomain
class.

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I have an application whose main function is encapsulated in encased
in a try/catch block catching Exception. My application has crashed
on several occasions with a CLR exception.

CLR exception - code e0434f4d (!!! second chance !!!)

So far I have been unable to create a test case that reproduces the
crash. My application makes extensive use of asynchronous programming
using waithandles.

Are there exceptions that "Exception" simply does not catch?

Amy.

 

[amyl]

[...]
If you want a generic catch-all for all threads in your app domain,
you
might want to check out the static UnhandledException event on the
AppDomain
class.

Noting, of course, that that doesn't actually handle the exception. It
just provides a way to know the exception occurred as the unhandled
exception causes the application to exit.

To the OP: if you wrote the code that's running in the other thread, then
to handle exceptions in those threads you can wrap _that_ code with a
separate exception handler (try/catch), just as you've done for the main
thread.

Pete

The problem I see now is that the exception is occurring in a
commercial DLL that I did not write (.Net 2.0 DLL). I have not been
able to grab any real info to pass back to the developers of the
component to help isolate the problem. Will I be able to get some
real exception data out of the AppDomain UnHandledException?

Amy.

 

[Peter Duniho]

The problem I see now is that the exception is occurring in a
commercial DLL that I did not write (.Net 2.0 DLL). I have not been
able to grab any real info to pass back to the developers of the
component to help isolate the problem. Will I be able to get some
real exception data out of the AppDomain UnHandledException?

I don't know...I try to avoid third-party code as much as possible,
because it's so hard to find third-party code that doesn't suck.

That said, if you cannot get useful information by catching the exception
explicitly (for example, putting a try/catch around the call to the
third-party code), I would be surprised if the UnhandledException event
provided more information. But don't take my word for it...I don't have
enough experience in the area to be a useful resource.

Pete