Call a subVI which includes dll-calling dynamically in run-time system, it fails.

[Nothings]

Hi all,

  In my program, I call a subVI which includes dll-calling dynamically in run-time system, but it fails.

  If I run it development system, it is OK.

  If I call the subVI not dynamically via invoke node but directly, it is OK both in run-time system and development system.

  All the failures are the dll return error, but the calling of subVI is success.

  I had tried to set the calling thread of the dll both in UI thread and in any thread, but it doesn't make any sense.

  Looking forward to your reply! Thank you very much!

[rolfk]

Seems you have included the dynamic VI in your build settings. Where does the DLL get installed that this VI calls?

Can you show us some of your code? Debugging something like this in the dark is very much like driving car with a blindfold on. You may get to the intended place but for sure with a lot of hit and miss!

Best approach is to create a small sample application that experiences the same issue. Chances are also, that you will find out the problem yourself as you create that sample app.

[NarayananK]

While the DLL is called dynamically, hope the path to the dll are returned in run time and development enviornment appropriate.

Could log the path to the dll in a text file and check the same.

Also, more details on the error code and debug details would help in suggesting possible soultion.

[Nothings]

Thank you rolfk & NaruF1🙂

Problems has been solved. Seems it is the problem of the dll file itself. I alternated the previous dll with another one, which has the same function with it. Then the run-time program runs well. I don't have the code of the dll so it looks like a black box to me. I can do nothing but change it into another one,

By the way, I don't have much experience on dll programming, are there anything about dll that can make a dll file can not be dynamically called in run-time systems?

[rolfk]

DLLs can depend on other DLLs. The primary DLL LabVIEW can reference by absolute path but the DLL dependencies are only stored by name (and version if they contain a SxS manifest for them). So the resolution is done by Windows looking in its standard search paths. A pretty common trouble is the C runtime library that every DLL made with Visual Studio will usually depend on. Depending on which Visual Studio version was used it will require a different runtime version and if using VS 2005 or 2008 it will even require a specific SxS version of that runtime library. Depending on what Windows version you have and what other applications you may have installed on that system, the required C runtime library may or may not be installed on your system. And then loading of a DLL fails, if Windows can't resolve even one single dependancy.