Question about debugging a DLL.

Question

The most common use of LV for us is to provide a GUI that then calls some DLL’s that then interface to our chip. To complicate things there are at least two families of our part and they use two different DLL’s. To further complicate things, the DLL’s also call other DLL’s to complete the interface.  To complicate things even further, no one here really knows the inner workings of these DLL’s. The person who wrote them no longer works here.
The crux of the issue is as follows: some time ago, I wrote a test suite for one of these families (call it family A). It works fine. My coworker wrote a test suite for the other family (call this family B). His test suite works just fine.
My coworker is in the process of combining the two test suites into one big test suit. When he runs his big test suite, he gets an error when he tries to access device in family A. The error indicates that an unhandled exception has occurred in the DLL.
Debugging is complicated by the fact that these test suites are not simple. We wrote a simple test program that simply initializes the family A device and reads a register. This runs without error. What is interesting is that if we run this simple test program, leave it in memory, then run his combined test suite, the combined test suite seems to work. But if we close the simple test program, the combined test suite fails.
Here is my guess: I think that the DLL’s that are called by the two test suites each call an intermediate DLL (or two) before actually talking to the device. One or more of these intermediate DLL’s have the same name between the two packages but are different in functionality. If we load his combined test suite, the existing code (code that was there before he combined the family A test code) loaded one of these intermediate DLL’s with the correct name but the wrong functionality for family A. Thus, when we run the combined test suite on the family A device, we get an error. But if we run the simple test program first, then it will load the intermediate DLL that has the same name but the correct functionality. If we leave that program open (but not running), when we open the combined test suite, it sees that the intermediate DLL is already loaded and doesn’t do it again. This would leave the correct intermediate DLL in memory. When we run the combined test suite, the correct set of DLL’s is in memory and everything works.
That is the theory. The trouble is that we don’t know what intermediate DLL’s are being called. We are pretty certain that the top level DLL (the one that is called by our LV code directly) is named differently between the two families and is being correctly pointed to by the Call Library nodes. After that, I have no knowledge or control.
Now, after all that, my question is: does anyone know of a tool or method that would help us confirm or dispute this theory or otherwise help us debug this?
thanks,
Joe

Answer 1

Have you browsed the VI Hierarchy of your test suites? This will expose any libraries directly referenced by your LabVIEW application.
Do you have the source code for the DLL?
Also, check out these two StackOverflow questions:
http://stackoverflow.com/questions/220515/how-to-intercept-dll-method-calls
http://stackoverflow.com/questions/3189117/how-to-listen-to-dll-function-calls
a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"] {color: black;} a.lia-user-name-link[href="/t5/user/viewprofilepage/user-id/88938"]:after {content: '';} .jrd-sig {height: 80px; overflow: visible;} .jrd-sig-deploy {float:left; opacity:0.2;} .jrd-sig-img {float:right; opacity:0.2;} .jrd-sig-img:hover {opacity:0.8;} .jrd-sig-deploy:hover {opacity:0.8;}