Deadlock in 3rd Party dll

Question

I'm using (and referencing) two 3rd party dlls (a.dll, and b.dll) in two of my C# applications. I'm getting a repeatable problem where both applications hang while making a call to a function in the 3rd party library.

I tried to make a copy of a.dll and b.dll (a2.dll, and b2.dll) and use that in the second application, but it turns out that a.dll references b.dll, anb b.dll references a.dll and this does not load properly.

I suspect that there is a deadlock but in the 3rd party library. I can't use locking to prevent this. Each application enforces locking to make sure that that app only has one thread accessing the library at a time, but I can't lock across both programs.

So, my question is how can I solve this problem?

Can I tell the OS (Windows XP) that I don't want the dll to be shared?

Thanks, Joe

Answer 1

What about creating another thread - which is responsible for accessing this dll...That way the whole app doesn't freeze

Answer 2

You can restrict access so only a single program at a time by using a named mutex. Named mutexes are restrictable to an entire operating system, so can be used to prevent access from multiple processes.

See the Mutex class for details.

Answer 3

Are these distinct applications? In that case, you shouldn't have any issues with single threaded access, as each process will handle that correctly. Can you clarify why you think there is a deadlock.

Answer 4

1) One way

• Create a server application, which exports/implements the 3rd-party API, and makes the API available to other/remote processes (e.g. by using dot net remoting, or a web service, to expose the API over the network).
• Within the server application, implement its API by delegating to the third party DLLs
• Start only one instance of the server application: there's therefore only one instance of the 3rd-party DLLs being used
• Have your existing applications use the API exported by your service, instead of using local instances of the 3rd-party DLLs
• Within your service, implement locks (which you can because it's now within a single process).

2) Another way: use a kind of lock that's visible accross more than one process (e.g. the Mutex class).

3) Ask the vendors of the third-party DLLs: are you supposed to be able to run only one instance of this DLL at a time? If you are allowed to run more than one instance, what must you do to avoid deadlocks across processes?

Answer 5

I once had a similar problem with a discontinued 3rd party product.

There I used a disassembler and a hex editor with an integrated assembler to fix the underlying bug, but that was more or less luck because the cause was something trivial which could be derived by looking at the disassembly.

Depending on the actual cause that might be an option for you.