I am having intermittent issues calling DLL functions from other DLLs. Here is the sequence of events that cause an error:
1) TestStand executes a function in a LabWindows DLL (call this “DLL A”)
2) “DLL A” loads “DLL B” and calls a function within
3) “DLL B’s” function calls a function in a .Lib that is included in “DLL C”
After between 2 hours and 2 days the software fails in “DLL C”. In the LabWindows debugger under threads I see we are sitting at the top of the function called in the .Lib “DLL C”. No failures/execeptions occurred, it’s just sitting there. It doesn’t appear to be starved of processor resources and there is only 1 other active thread – a socket listener thread that has plenty of non-blocking delays/processSystemEvents/etc.
If you need some context: TestStand calls a generic “DLL loader” (DLL A), which in this case, calls a generic discrete IO DLL (DLL B), which calls a specific-model discrete IO driver DLL (DLL C). I am making a TestStand/LabWindows solution that is driven from configuration files. In doing so I’ve run into some intermittent problems with this DLL hierarchy that sometimes doesn’t allow me to run overnight (which is a requirement).
Is there an issue dynamically loading and using a DLL that has statically linked a library file? I’ve been looking at this issue for weeks, Help!! Please let me know if there is any information I can provide - I am using NI Developer Suite 2011.
To answer your bolded question; I think that there shouldn't be any issue with that, especially since your program works fine, but only crashes intermittently.
Have you made sure that you are using the IO driver DLL correctly with your device? It could be that the device is hanging due to improper closing and opening of references to the device. What device are you connecting to and where did you obtain the IO driver DLL?
I have also seen intermittent behavior such as this due to background processes on the computer such as Windows and security updates.
Try running the program without being connected to the network.
Jacob R. | Applications Engineer | National Instruments