13

I am writing a multi-threaded application that relies on some third party DLLs. My problem is that when using an object from the third party library, if it raises an exception while running, I am unable to catch it and it bubbles up and kills the entire application. I have many different threads each using its own object from this third party library and I need the thread that was using that copy of the object to be able to catch and deal with the exception.

Based on what I've read, it seems like most likely the 3rd party library is actually making its own threads and allowing uncaught exceptions. The .NET 2.0+ behavior allows these exceptions to kill the entire application. I'm aware of AppDomain.CurrentDomain.UnhandledException, but that does not allow you to prevent application shutdown.

For reference, I'm writing a console application in .NET 4.0. Does anyone have any solution/advice to stop these exceptions from killing my application?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
DrSpock
  • 377
  • 2
  • 4
  • 6
  • If you can't catch the exception, how do you know that an exception was thrown? It could be that the DLL is simply corrupting memory. Is it a .NET DLL? Also, what do you want to do when one of these exceptions happens? You can't continue, since you don't know the state of the DLL. All you could do is display a pretty message before terminating your entire application. – John Saunders May 27 '11 at 23:07
  • In the same boat: badly written 3rd party lib using Timer callbacks that don't catch exceptions.... Conclusion we are coming to for true isolation is to have separate processes rather than child AppDomains – Peter McEvoy Mar 24 '15 at 11:05

3 Answers3

9

One thing you might look at is the HandleProcessCorruptedStateExceptionsAttribute attribute.

I don't know if this is your problem or not, but I had to recently use this attribute on a method that was calling a function in a third party COM object. This attribute is new to .net 4.0. My basic understanding is that the 4.0 framework will by default not bubble up an exception thrown in certain situations where it feels the 3rd party exception may have introduced some instabilty. I think this pertains mostly to situations where the 3rd party component is unmanaged. I am not sure, but it resolved my issue.

The usage looks like this:

[System.Runtime.ExceptionServices.HandleProcessCorruptedStateExceptionsAttribute()]
private void ThirdPartyCall()
{
    try
    {
            return Call3rdPartyFunction()
    }
    catch (Exception exInstantiate)
    {
        ...
    }
}

More information: http://msdn.microsoft.com/en-us/magazine/dd419661.aspx

Mariusz Jamro
  • 30,615
  • 24
  • 120
  • 162
Jeremy
  • 44,950
  • 68
  • 206
  • 332
  • Hi, thanks for the responses, but unfortunately I am still having the same issue. The DLL in question is managed code, but I am unable to catch Exceptions stemming from it. I know that the instance the exception comes from needs to be shut down, but the rest of the application running on other instances does not need to be closed. It's not an out-of-memory thing or anything that seriously, just an Exception representing a script error. If it helps, I'm referring to the Selenium .NET component. – DrSpock May 30 '11 at 13:47
  • @DrSpock - the method you are calling that throws the exception, are you calling from within a thread? and you are wrapping it in a try catch? If you put a breakpoint on the catch, it never breaks? – Jeremy May 30 '11 at 16:25
  • Hi, yes to all three of those questions. – DrSpock Jun 01 '11 at 15:25
  • Thank you sir, I was having a problem with AccessViolationException that I couldn't catch with the catch statement. https://learn.microsoft.com/en-us/dotnet/api/system.accessviolationexception?view=netframework-4.8 – Nhân Nguyễn May 13 '19 at 04:13
6

The issue is probably that exceptions thrown on background threads are not caught once they bubble out of the thread proc.

This seems like a non-obvious duplicate of How to prevent an exception in a background thread from terminating an application?

Community
  • 1
  • 1
hemp
  • 5,602
  • 29
  • 43
  • 1
    +1 I agree with you about the dupe. And if something is going to bring down the app, you can't really stop it; unless a) the code is fixed or b) you cut it out of the app – Andras Zoltan May 27 '11 at 21:20
1

You can stop application crash by doing this:

    AppDomain.CurrentDomain.UnhandledException += (sender, e2) =>
    {
        Thread.CurrentThread.Join();
    };

But uncaught exception from 3d party components mean that components don't do their job properly. If you don't care if they don't do the job better don't use them.

Evgeny Gorbovoy
  • 765
  • 3
  • 20