Can not get Call Library Function Node working

[evi7538]

I'm trying to get a most primitive DLL working with LabView using Call Library Function Node. I built this simple DLL "ArionDLL.dll" in Visual Studio C++ 2017 together with a client console app ArionDllRun.exe to test it, the code is below. The client console app runs just fine and calls the DLL with no errors. When I try to use this DLL in LabView I get a broken arrow and the error message is: Library not found or failed to load. 

Any help would be much appreciated!

[evi7538]

Forgot the source code. I also ran dependencies check on ArionDLL.dll, it's showing the VCRUNTIME140_APP.dll with question marks, could that be the problem?  

[wiebe@CARYA]

---

@evi7538 wrote:

 I also ran dependencies check on ArionDLL.dll, it's showing the VCRUNTIME140_APP.dll with question marks, could that be the problem?  

---

Yes, that could be the problem. That dll needs to be visible for LabVIEW. So it needs to be in one of the search paths, in a subdirectory of the main (I'd put it next to the dll to be sure) or in Windows\system32 directory.

You can probably configure C\C++ to compile with static binding of that library, so it won't depend on it. At the cost of a bigger dll of course.

[evi7538]

---

You can probably configure C\C++ to compile with static binding of that library, so it won't depend on it. At the cost of a bigger dll of course.

---

Hmm, thanks for the tip but how would I do that (I'm a hobbyist, please bear with me)? I guess I need to explicitly call the function that is used in my DLL from that library inside one of the executable functions in my DLL in order to get it bound statically? I guess I can find out what functions that DLL has using dumpbin commands but how do I know which function from this VCRUNTIME140_APP is actually called by my DLL at runtinme?

Or if I just call any function from VCRUNTIME140_APP in my DLL will it statically bind the whole VCRUNTIME140_APP library?

[evi7538]

---

wiebe@CARYA wrote:

---

@evi7538 wrote:

 I also ran dependencies check on ArionDLL.dll, it's showing the VCRUNTIME140_APP.dll with question marks, could that be the problem?  

---

Yes, that could be the problem. That dll needs to be visible for LabVIEW. So it needs to be in one of the search paths, in a subdirectory of the main (I'd put it next to the dll to be sure) or in Windows\system32 directory.

---

I guess my other question is: why this VCRUNTIME140_APP.dll dependency is a problem for LabVIEW and NOT a problem for my client console application that calls my ArionDLL? If my console app does not have this dependency problem then it means that the VCRUNTIME140_APP.dll must be somewhere under one of the directories defined in the system PATH, right? Then why LabVIEW would have problem finding it?

[wiebe@CARYA]

---

@evi7538 wrote:

---

wiebe@CARYA wrote:

---

@evi7538 wrote:

 I also ran dependencies check on ArionDLL.dll, it's showing the VCRUNTIME140_APP.dll with question marks, could that be the problem?  

---

Yes, that could be the problem. That dll needs to be visible for LabVIEW. So it needs to be in one of the search paths, in a subdirectory of the main (I'd put it next to the dll to be sure) or in Windows\system32 directory.

---

I guess my other question is: why this VCRUNTIME140_APP.dll dependency is a problem for LabVIEW and NOT a problem for my client console application that calls my ArionDLL? If my console app does not have this dependency problem then it means that the VCRUNTIME140_APP.dll must be somewhere under one of the directories defined in the system PATH, right? Then why LabVIEW would have problem finding it?

---

That is indeed questionable. The calling client could be in a directory where the dependency is also placed? Of the calling client could be statically linked to that library? Not really sure.

But non the less, I'd first make sure LabVIEW can find it, just to rule out or confirm this as the problem. First find the problem, then the details and\or solution.

Changes are it's something completely different...

[rolfk]

---

@evi7538 wrote:

---

wiebe@CARYA wrote:

---

@evi7538 wrote:

 I also ran dependencies check on ArionDLL.dll, it's showing the VCRUNTIME140_APP.dll with question marks, could that be the problem?  

---

Yes, that could be the problem. That dll needs to be visible for LabVIEW. So it needs to be in one of the search paths, in a subdirectory of the main (I'd put it next to the dll to be sure) or in Windows\system32 directory.

---

I guess my other question is: why this VCRUNTIME140_APP.dll dependency is a problem for LabVIEW and NOT a problem for my client console application that calls my ArionDLL? If my console app does not have this dependency problem then it means that the VCRUNTIME140_APP.dll must be somewhere under one of the directories defined in the system PATH, right? Then why LabVIEW would have problem finding it?

---

Well the Dependencies utility can't seem to find the DLL either as indicated by the question mark so that is an indication that it may not be in a generally visible path on your machine but only in a private path to your console application. It's not a sure way to detect such problems though as the Dependencies utility hasn't really been updated to deal with 32/64 bit DLL differences properly as well as that it can not handle SxS (side by side library installations) properly, something Microsoft itroduced somewhere between Windows XP and Vista to work around DLL hell situations by a solution that replaces DLL hell with DLL Tartarus 

[evi7538 · Accepted solution]

So I went through these steps:

1. I found that the vcruntime140_app.dll is missing in Windows/System32 so it's probably some secret Microsoft dll hiding somewhere in the Visual Studio directories. Downloading it and placing under System32 fixed the question mark in the Dependency checker, but not the broken arrow in the LabVIEW.

2.Then I also placed the vcruntime140_app.dll into my LabVIEW project folder and that fixed the problem with LabVIEW broken arrow so my VI now works fine.

May be is has to do with the fact that I'm using LabVIEW 2014 Home edition. Anyway, thanks to all who responded, problem solved.

[rolfk]

---

@evi7538 wrote:

May be is has to do with the fact that I'm using LabVIEW 2014 Home edition. Anyway, thanks to all who responded, problem solved.

---

No! It has to do with the fact that you are using LabVIEW 32 bit on a Windows 64 bit system. On Windows 64 bit "Windows\System32" is reserved for 64 bit system extensions and 32 bit system extensions go into "Windows\SysWOW64" instead. You feel confused about the naming conventions? Well you are not alone but only Microsoft knows the reasons behind this.

A 32 bit application will not be able to see a 32 DLL placed inside System32 because even if it explicitly asks to load a DLL from there, the helpful Windows kernel will redirect the request to SysWOW64 no matter what.

[evi7538]

---

@rolfk wrote:

---

@evi7538 wrote:

May be is has to do with the fact that I'm using LabVIEW 2014 Home edition. Anyway, thanks to all who responded, problem solved.

---

No! It has to do with the fact that you are using LabVIEW 32 bit on a Windows 64 bit system. On Windows 64 bit "Windows\System32" is reserved for 64 bit system extensions and 32 bit system extensions go into "Windows\SysWOW64" instead. You feel confused about the naming conventions? Well you are not alone but only Microsoft knows the reasons behind this.

A 32 bit application will not be able to see a 32 DLL placed inside System32 because even if it explicitly asks to load a DLL from there, the helpful Windows kernel will redirect the request to SysWOW64 no matter what.

---

Oh boy, that is totally counterintuitive. I actually placed another 64-bit version of vcruntime140_app.dll under SysWOW64 (because I thought that it's the proper place for 64-bit system files, which turns out to be wrong). But I copied the right 32-bit version of this dll under my LabVIEW project so that's why it's now working I guess. May be I'll try to switch those dll versions between the SysWOW64 and System32 just to get it right. But the fact is - they were not there in the first place before I copied them there.

But in general it seems to be an issue with Visual Studio that its compiled dlls retain some hidden dependencies to some local libraries that are not in the system path and are not accessible for other applications. So now those libraries need to be dragged around together with the top-level dll to the applications that use that dll. At least their VC redistributables should place those "secret" libraries under common system directories declared in the PATH.