"Call Library Function Node" runtime Error 13 when running as .exe in Labview RTE 2013

[JoshC94]

Please delete if duplicate, the first post I made seems to have disappeared. 

I'm trying to deploy my labview code as an application for the first time and I'm encountering the classic problem of "it works on the dev machine but not on the target machine" 

I am using a 3rd party library to facilitate CAN communication between the machine running labview code and others, as well as an in house library with accompanying DLLs for both. I've been developing my code in labview 2013 32 bit and it works perfectly on the dev machine both as and exe and a VI.  On my dev machine, I have the whole labview 2013 development suite installed, I have the drivers for the CAN device, as well as the SDK for the CAN device installed, which includes a bunch of .VIs that have "Call Library" blocks that point to a DLL called labview_can.dll. The "Call library function" nodes are configured by the 3rd party.  The in house library is set up similarly. 

On the target machine, I have the drivers for the 3rd party CAN card, drivers for the in-house card, the full Labview runtime environment with the same version and bitness as the dev machine, and the folder containing the output of the build spec from the labview project on the dev machine. The same physical devices are installed in the target machine as the dev machine.

At first, when I built the app, i was getting the "Resource not found" error when trying to boot up the .exe on the target machine.  I moved project files around and then I was getting a different error when running the .exe on the target machine which stated "Missing external function:<lvlib><path to function within lvlib>".  I troubleshooted this for while and one of the solutions I tried was to build the path to the DLL on the block diagram in runtime instead of relying on a statically configured path.  By default, the .exe builds to its own directory, which contains a few files and a support directory called "data", where all the 3rd party DLLs reside. These include labview_can.dll (for the CAN device) and our in-house DLL. So, I modified every library function that I was using to build the path in runtime as shown in the attached image to point to the 'data' directory regardless of where the parent directory containing the .exe application was located (dynamic_path_modification.png). This solved the "missing external function" error and finally I was able to start the application and run it. 

However, all the VIs that call functions in labview_can.dll are giving the runtime error "Call Library Function Node in labview_can.lvlib:" (followed by stack trace) and giving error code 13.  As did some googling, and on a page called "General Labview Error Codes" 13 maps to

"Failed to load dynamic library because of missing external symbols or dependencies, or because of an invalid file format." which seems correct based on the context, but I don't know if this the right description. 

The calls to the in-house DLL are throwing the same runtime error.  

In the labview project, I dragged everything out of the dependencies category so there would be no question as to whether things were included.  The DLLs for the lvlibs that I'm having problems with are included UNDER the lvlib dropdowns in the 'items' view of the project file.  In the build spec, I have all the VIs and DLLs added to the "always included" pane of the "Source Files" window.  

Attached files that show the directory structure of the build result plus the structure of the project file and build spec. 

Let me know if I left out any important info. Your help is most appreciated, thank you.

[Kyle97330]

If you go to the "<user.lib>\labview_can\" directory, are there any DLLs in that folder besides "labview_can.dll"? 

If so, what happens if you move them to the data directory as well?

If not, can you install the the SDK for the CAN on the target machine, or does it generate an error if you try doing it without a LabVIEW install there?

[JoshC94]

I actually did this on my own before seeing this, but yes, that worked for the CAN functions anyways.

Using dependency walker I was able to see that there were other 3rd party DLLs that I was missing that were in fact in the labview_can folder.  I created a new, cleaner project and built the app and the CAN functions are now working.  Now I have to figure out what's missing for the in-house DLL! I did a dependency walker on it, and included one of the "top-level" DLLs that normally resides in the Windows\SysWOW64 folder just incase, but I wasn't sure why I would need that since the system already has it from the driver installation. No luck on that one though. 

[JoshC94]

Update: I'm still not able to get the function calls to the in-house DLL working and I'm really out of ideas.  The way that the labview library functions were created is as follows: 

Used the "Import shared library" tool in labview to create an lvlib full of VIs from a DLL and header, v5565_dll.dll and v5565_dll.h.  The DLL was built from a C source in visual studio 2010 on the development machine

When I use dependency walker on v5565_dll.dll, the only DLLs it's dependent on are ones that are installed with the driver, and native Windows DLLs. I tried including the 3rd party driver DLLs in the project just to be sure but no luck.  I really don't think there are any more files I can include in the project that could help the situation. There are no other DLL files associated with v5565_dll.dll in the user.lib folder in which it resides. Again, everything works fine on the dev machine as both exe and VI.

Included pictures of the dependency walker trace, the device drivers, the call library function node.  

[JoshC94 · Accepted solution]

I wanted to update this thread with the solution that I found a while back.  The problem was not anything related to labview.  The in-house DLL was dependent on a DEBUGGING VERSION of a native windows DLL that comes installed with visual studio 2010 (the development suite that was used to develop the inhouse DLL, yes I know - its old).  When I installed visual studio on the target machine, the VI was able to run without errors. 

The necessary DLL was msvcr100d.DLL (Microsoft visual studio 2010 redistributable C++ debugging version), which has been placed on all the target machines as opposed to installing visual studio 2010 on all of them. 

[rolfk]

You are technically illegally with this. the debugging versions of the Microsoft C runtime library are installed by Visual Studio and you accept in the license agreement that you have to accord to when installing Visual Studio to not distribute any files included in Visual Studio except what is explicitly allowed by it. And allowed are the files you generate yourself and the release version of the Microsoft C Runtime, but not the debug version. And there are specific redistributable installers for these runtimes that you should use to install the according runtime support.

Basically you should never ever distribute debug versions of a dll or executable, not even for in-house use. And not just for legsl license reason!

The only correct solution is to rebuild that dll as release version and add the redistributable C runtime library installer for your Visual Studio version to the install procedure of your application!

[JoshC94]

I see, never Imagined something with "redistributable" in the name would have this problem.  The project files are still around so this should be a short putt. Thanks for the heads up. 

[rolfk]

---

@JoshC94 wrote:

I see, never Imagined something with "redistributable" in the name would have this problem.  The project files are still around so this should be a short putt. Thanks for the heads up. 

---

Not sure what you are saying :-). The Debug versions of the C runtime libraries are NOT distributable. The Release versions are installed (usually through the redistributable installer) by whatever component was created with the particular Visual Studio version. So depending what Windows version you have and what other applications you have already installed it MAY be already installed. Most executables that come with Windows are created with the Microsoft C/C++ compiler which is also part of Visual Studio, and not all of them with the same version of the C/C++ compiler as it makes little sense to rebuild an executable if there haven't been any changes to its source code. Also most other applications including LabVIEW are also compiled with Visual Studio. Each application installer is responsible to include the necessary dependencies in its installation routine, so if you are lucky your machine already has the right C runtime library version installed for your own library.

But since you don't know ahead what specific setup your users computer will have (even if that user will be yourself in a year or more from now), you should always include the according redistributable C runtime installer into the installation procedure for your product. That can be fancy with a full installation setup program that you create, or more adhoc with a readme.txt file that tells the user to copy your DLL to wherever it makes sense (and explain to him what the constraints are) and to also run the included vcredist_x86.exe (or vcredist_x64.exe if your DLL is compiled for 64-bit).

You can download them from Microsoft (make sure to get the right version for your Visual Studio version) or also find them in your Visual Studio directory.

https://docs.microsoft.com/en-us/cpp/windows/redistributing-visual-cpp-files?view=msvc-140

For version before Visual Studio 2015 you need to check the included documentation.