1

We have a c# WPF app and we use a 3rd party SDK with a native C++ DLL, we call the methods with DllImport attributes.

Unfortunately code is not that great and that C++ DLL crashes our C# app.

Is there an elegant and efficient way to isolate the calls to the C++ DLL so their exceptions don't crash our app? We are getting a stream of images and data so it needs to be fast.

We use WCF to offload some operations in a windows service, so we have an infrastructure to do this, but I don't think it will be fast enough to transfer data and image buffers to/from it.

Would a different AppDomain be a good choice? Any examples how to do this?

thanks

dan
  • 801
  • 15
  • 41
  • 1
    The DLL needs to run in a different process then, you could use native C++ to build that code. A memory-mapped file or other shared memory scheme might be fast enough for bulk data transfers. If the process dies, spawn a new one. – Dave S Mar 08 '18 at 00:45

4 Answers4

0

Its probably the right behaviour to terminate the app in this situation. If you have control over the DLL I would consider handling its exceptions differently

From memory, i believe (in early versions of .Net) you could just catch via ExternalException class:

Note : .NET v4 and above it disables the delivery of certain exceptions by default

To reenable this i 'believe' you can just edit your manifest or use an attribute, take a look at

legacyCorruptedStateExceptionsPolicy Element

HandleProcessCorruptedStateExceptionsAttribute Class

TheGeneral
  • 79,002
  • 9
  • 103
  • 141
0

a similar crash occured to me not long ago.I think first you should resove the native dll error . There is no way that you can use to catch an exception from a native code.

cn-deng
  • 51
  • 1
  • 8
0

The only way to make sure the C++ DLL does not crash your C# process is to move it to another process which you can restart if it crashes.

You can wrap the C++ DLL in a separate application / service and communicate with your C# application via named pipes to transfer the image data. You will also need some kind of heart beat to detect if the wrapper crashed and restart it as needed.

We implemented this solution for a microscope which came with an ActiveX component that kept crashing our application. This approach worked well and was fast enough.

Marius
  • 1,529
  • 6
  • 21
0

AppDomains don't provide isolation for native assemblies as they use unmanaged memory, due to this I'm not sure if an access violation in a secondary app domain will bring down your whole process.

I'm guessing that your problem is due to state corruption. So before trying to outboard the service you can try catching those exceptions.

How to handle AccessViolationException

So long as the library itself can recover, you might be OK. Worth giving a go.

satnhak
  • 9,407
  • 5
  • 63
  • 81