How to reload a 3rd party DLL that crashes often

Question

I'm using a 3rd party DLL written in unmanaged C++ that controls some hardware we have.

Unfortunately this DLL crashes now and then and I've been tasked to make it "reload" automagically. I'm not too sure about how to proceed to get best results.

My project uses C++.Net 2.0 (2005). I'm wrapping the 3rd party stuff in a separate DLL. I've been trying to FreeLibrary() and LoadLibrary(). However when I FreeLibrary(), some internal DLL dependencies remain allocated and LoadLibrary() will make it crash because of corrupted memory.

Another approach that was suggested was to refactor the whole project using .NET remoting interfaces. It would make it easier to kill another process and restart it but it will be a lot of work.

Any suggestions? Pointers? Hints?

Answer 1

I'm not a windows expert, but I think the general idea should hold.

LoadLibrary, FreeLibrary deal with mapping a DLL onto the process memory space. The corruption you are seeing is due presumably to some code inside the DLL doing something "bad" and almost certainly corrupting the process memory. Now If it's crashing, it's almost certainly killed the thread it was running in - if not the whole process.

I would take an educated guess that the only way to reliably recover and ensure non-corrupted memory is to run a sacrificial process as a wrapper round the rogue DLL. I assume the remoting interfaces are one way of doing this. There may be others.

Answer 2

LoadLibrary and FreeLibrary are the start, but you then need to wrap all calls into the DLL in SEH (structured exception handling) __try / __catch blocks if you want to be able to ride out a crash within the DLL. N.B. this is quite different from C++ exceptions and try/catch blocks. See MSDN for more information.

Answer 3

If the DLL itself is crashing and your company will go for it, it might be worth investing the time to recreate it. Better to fix the problem instead of just bandaiding it.

Answer 4

The most effective approach will be to not load that DLL in your application's process at all. Instead, create a second process whose only job is to use that DLL on behalf of your application. You can use a shared memory region, local socket, or other IPC mechanism to control the proxy process.

This way, when the problematic DLL crashes, you can simply allow the proxy process to die without worrying about the (nearly impossible) task of trying to make sure the DLL didn't corrupt anything important on its way down. Your main process need only start a new instance of the proxy process and carry on.