LabVIEW can't find function in dll

[stancilmor]

    I have a .dll file labviewadapterd.dll that was made to process some data.  As you can see in pic1.jpg I have placed the Call Library Function Node on the block diagram, right clicked, and selected Configure.  I used the browse button to select the labviewadapterd.dll file and then the Function name drop down menu to select a function.  Then I clicked on the Parameters tab and used the labviewadpaterd.h file to setup the parameters.  When I clicked on OK to finish up the configuration.  I received the error in pic2.jpg (error loading labviewadapterd.dll the application failed to start because the application configuration is incorrect).   This error makes no sense to me, because there is no application just a dll.  I tried rebooting the machine and placing my VI in the same directory, but I still got the same error. 

For the sake of completeness I clicked on the broken run icon and the error message displayed is in pic3.jpg (function not found in library).  How can LabVIEW not find the function when I initially selected it from a drop down menu that LabVIEW gave me?  Any ideas on how to resolve the issues I am having?

The labviewadapterd.dll was created using Microsoft Visual Studio 2005 and the lib files found in the National Instruments\Labview 8.5\cintools folder.

Three pictures of screen shots are attached

regards,

[smercurio_fc]

Slight clarification query: are you trying to create a CIN or a DLL? The reason I ask is that you're linking to the lib files in the cintools folder. Or, are you trying to use LabVIEW functions and/or datatypes in your DLL? Does your DLL depend on another DLL?

[Acshi]

You used Visual Studio, so most likely, your dll is not using the C calling convention, unless you used Visual C++ with special compiler settings.

Therefor, although the initial dll inspection shows the functions contained in the dll, when the dll is actually inspected, LabView does not find what it expects.

If you are using .Net with Visual Studio, you can use the much more conveniant Connectivity -> .Net, subVi's, which give much greater control than the Call Library Function Node does.

[rolfk]

---

smercurio_fc wrote:
Slight clarification query: are you trying to create a CIN or a DLL? The reason I ask is that you're linking to the lib files in the cintools folder. Or, are you trying to use LabVIEW functions and/or datatypes in your DLL? Does your DLL depend on another DLL?

---

Actually its completely valid for DLLs to link to the labview.lib file in the cintools directory although it will only do so if you do use LabVIEW manager functions in your C code.

Your last sentence however is likely the point. The DLL most likely links to other link libraries that import from third party DLLs. On initial inspection LabVIEW reads the export table of the selected DLL directly to populate the function selector. This is the only way for an application to find out about what functions a DLL exports.

Then after the function configuration is finished and closed, LabVIEW tries to load the library and link to the function using LoadLibrary() and GetProcAddress() Windows APIs. However LoadLibrary() will fail if the DLL links to other DLLs that Windows can't resolve. Here comes then the catch all dialog that says, sorry couldn't load the DLL OR link to the function. Something is messed up!

The OP should look for other DLLs that he might be using in his code and make sure that he has them and any other dependant DLL of those in one of the well known Windows shared library search locations asI have pointed out many times, as Windows will look for DLLs as follows:

1) DLL already loaded in the application independant of the actual absolute path specified

2) if the path is absolute at that specific location and if not found the loading will fail here

3) in the application directory (where the exe resides that launched the current process)

4) in the System directory

5) in the Windows directory

6) any directory listed in the PATH environment variable

7) in the "current directory" a variable that is maintained per process and updated by various Windows API functions that access directories 

LabVIEW will first try to load the library with an absolute path at the last known location. If that fails it retries with just the DLL name to let Windows search for it in its well known locations.

Rolf Kalbermatter

Message Edited by rolfk on 01-22-2009 09:11 AM

[smercurio_fc]

I also figured the most likely cause was that a dependency on another DLL, but as the regulars on here know, folks often get the terms CIN and DLL confused, and assume they're the same thing. The only reason why I mentioned it was that the OP was referring to the cintools folder, though as you noted, you may still need to do so while creating a DLL.

[stancilmor]

Thank you for the insight.   I wasn't the one that wrote the dll code, but I did some checking and it seems that the dll that I call from LabVIEW calls at least two other dlls.  One was also compiled in visual studio, but the other one is a 3rd party dll in a directory of other dlls that it may or may not call.  I setup my environment PATH to include those dlls and will give it another try once the machine reboots.  If that doesn't work, I'll try putting everything in the same directory or even in the Windows\system folder.

Ok the above didn't work..same can't find my top fuction.  It would be nice if LabVIEW could indicate which function or dll was missing when there was a chain of dll calls.  I will check with the 3rd party as it seems their dlls have changed naming conventions to include the release version.  I think my dll expects to find the 3rd party funtions in name.dll, but the functions are now in nameversion.dll.

I'll post back if that fixes it.

[rolfk]

---

stancilmor wrote:

Thank you for the insight.   I wasn't the one that wrote the dll code, but I did some checking and it seems that the dll that I call from LabVIEW calls at least two other dlls.  One was also compiled in visual studio, but the other one is a 3rd party dll in a directory of other dlls that it may or may not call.  I setup my environment PATH to include those dlls and will give it another try once the machine reboots.  If that doesn't work, I'll try putting everything in the same directory or even in the Windows\system folder.

Ok the above didn't work..same can't find my top fuction.  It would be nice if LabVIEW could indicate which function or dll was missing when there was a chain of dll calls.  I will check with the 3rd party as it seems their dlls have changed naming conventions to include the release version.  I think my dll expects to find the 3rd party funtions in name.dll, but the functions are now in nameversion.dll.

I'll post back if that fixes it.

---

Unfortunately when you tell Windows to load a DLL the loading either succeeds or fails.

No other detailed information is available from Windows so the only way LabVIEW could tell you this detailed info is by trying to resolve all import tables itself which would mean LabVIEW would be emulating the whole Windows dynamic link loading itself. That can't be the purpose, can it?

Rolf Kalbermatter 

[stancilmor · Accepted solution]

It seems the problem of loading dll's generated by Microsoft visual studio can be solved by generating redistributable dlls instead of debug versions and also installing the Microsoft redistributable library for the appropriate language used to write the dll.

[rolfk]

---

stancilmor wrote:
It seems the problem of loading dll's generated by Microsoft visual studio can be solved by generating redistributable dlls instead of debug versions and also installing the Microsoft redistributable library for the appropriate language used to write the dll.

---

Sounds very logical. When you create a Visual Studio project it sets its debug build target to link with the debug runtime libraries. These are seldom installed on a computer unless you have installed Visual Studio itself. Also while you can redistribute the non-debug versions of the runtime libraries with your build application MS does not grant you that right for the debug versions of the runtime libraries. So distributing debug versions of your Visual Studio application to other users is usually not helpful since they most of the time miss the runtime libraries to run them and you are legally not antitled to distribute them to your end user.

If you happen to have some debug features in your application that are only included in the debug build and want to distrubute that application to other users you should create a new target version in your project that defines whatever symbol enables your debug feature in your source code but ensure that in the link settings you link to the non-debug runtime libraries. The debug runtime libraries are really only useful if you happen to do source level debugging and want to be able to trace into the C runtime source code for some reason. The only other reason why you might want to run with debug instead of non-debug on other systems than your own test systems would be bugs that show not in when using the debug version, but that would be like trying to use bandaid to prevent your house from falling apart. It is caused by race conditions in the code and will certainly show up on other users computers sooner or later even with debug libraries.

Rolf Kalbermatter