2

I have an application that uses a DLL to make API calls. Is there a way to prevent my application from crashing when the DLL crashes? I tried putting a try/catch around each call, but that doesn't work.

Justin Ethier
  • 131,333
  • 52
  • 229
  • 284
Robert
  • 6,086
  • 19
  • 59
  • 84
  • 2
    How is the DLL "crashing"? Throwing an exception? Stack overflow? Null pointer reference? Is the DLL managed or unmanaged code? – dthorpe Aug 27 '10 at 19:37
  • 1
    Not all exceptions can be caught. DUN DUN DUNNNNNN! (Won't somebody think of the children!) – Jimmy Hoffa Aug 27 '10 at 19:39
  • The DLL is managed code and the exceptions are typically null pointer references or dictionary key errors. – Robert Aug 27 '10 at 19:53

4 Answers4

3

If the DLL is a third-party library you cannot modify you can load and execute the code in a separate AppDomain.

If it is your own code it would be best to fix the bugs first. A NullReferenceException almost always indicates a bug in your code that should be fixed.

As you are not able to catch the exceptions with a try/catch blog I would assume that the exception occurs on another thread. Either wrap the method(s) on the other thread within a try/catch block or use the AppDomain.UnhandledException event to catch it.

Dirk Vollmar
  • 172,527
  • 53
  • 255
  • 316
  • Troublesome. Important help is here: http://blogs.msdn.com/b/clraddins/archive/2007/05/01/using-appdomain-isolation-to-detect-add-in-failures-jesse-kaplan.aspx – Hans Passant Aug 27 '10 at 21:08
  • @Hans Passant: Great read, thanks. To clarify: I meant to use the AppDomain approach only if the dll cannot be modified. – Dirk Vollmar Aug 27 '10 at 21:29
1

It is not the DLL that crashes, it is your thread that suffers the heart attack. It cannot continue, which usually means your process is done for as well. Trying to handle the exception is rarely possible, you don't know what kind of damage was done.

Running it in a separate process is the only reasonable workaround. Although trying to recover from this process suddenly dying is unreasonably hard.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
1

There are certain conditions that will always cause a process to exit, like for instance StackOverflow in managed code, touching guard page and failing to commit a reserved stack page on any process (no room to put the EXCEPTION_RECORD) and some other. If you want to protect your process from a crash caused by a DLL you'll have to invoke the DLL from a different proxy process. Launch a dummy process that serves only as a host for the DLL calls and then communicate with this process with IPC means (shared memory, net pipes etc). If the process crashes, you'll have the means to detect it and proceed accordingly. This is way more complicated than a try/catch, but is perfectly doable in C#. Understand that you'll need a separate application as your crash test dummy process.

Community
  • 1
  • 1
Remus Rusanu
  • 288,378
  • 40
  • 442
  • 569
1

You can protect your application if instead of referencing the DLL you dynamically create a domain and load the DLL into it. It is not easy and I've found DLLs that will not execute some of their own methods when run that way, but it will protect your application if you can do it. The effort may not be worth it though. Another approach might be to try detecting the conditions that cause the DLL error before calling the method.

jac
  • 9,666
  • 2
  • 34
  • 63