How to reload a third-party DLL that often crashes

Question

I use a third-party DLL written in unmanaged C ++, which manages some of the equipment that we have.

Unfortunately, this DLL causes crashes from time to time, and I was instructed to make it "reboot" automatically. I'm not too sure how to start getting better results.

My project uses C ++. NET 2.0 (2005). I wrap third-party material in a separate DLL. I tried to use FreeLibrary () and LoadLibrary (). However, when I FreeLibrary (), some internal DLL dependencies remain allocated, and LoadLibrary () will crash due to corrupted memory.

Another approach that was proposed was to reorganize the entire project using .NET remote access interfaces. It would be easier to kill another process and restart it, but it will be a lot of work.

Any suggestions? Pointers? Tips

Answer 1

The most efficient approach is to not load this DLL into your application process at all. Instead, create a second process whose only job is to use this DLL on behalf of your application. You can use a shared memory area, local socket, or other IPC mechanism to control the proxy process.

That way, if the problematic DLL crashes, you can simply let the proxy die without worrying about the (almost impossible) task, trying to make sure that the DLL has not damaged anything important in its path. Your main process only needs to start a new instance of the proxy process and continue.

Answer 2

I am not a window expert, but I think the general idea should be implemented.

LoadLibrary, FreeLibrary manages to map the DLL to the process memory space. The damage you see is apparently due to some code inside the DLL that does something “bad” and almost certainly distorts the process memory. Now, if it crashes, it almost certainly killed the thread in which it worked - if not the whole process.

I would like to get a reasonable assumption that the only way to reliably restore and ensure intact memory is to start the sacrificial process as a wrapper around the rogue library. I assume that remote interfaces are one way to do this. There may be others.

Answer 3

LoadLibrary and FreeLibrary is the beginning, but then you need to wrap all the calls in the DLL in __try / __ catch blocks to handle SEH (structured exceptions) __try / __ catch if you want you to crash the DLL. Notably this is very different from C ++ exceptions and try / catch blocks. See the MSDN for more information.

Answer 4

If the DLL itself crashes, and your company does it, it may be worth the time to recreate it. It’s better to fix the problem, not just dress it up.