"Function not found in library" with Visual Studio 2017 C++ MFC DLL running in Windows XP

[NathanD@Triumph]

I have a proprietary DLL as well as supporting EXE's to manage test computer IO and automation that we have developed in-house over the last decade-and-a-half. We have been using functions from this DLL within LabView VI's for just about as long. Our test lab is still standardized on LabView 6. I have just completed the process of updating the DLL to continue development in Visual Studio 2017 and have encountered "Function not found in library" errors.

• The errors only occur when running our test VI's on older Windows XP machines. 
• The same VI's run perfectly fine with this new version of the DLL on newer Windows 10 test machines (also running LabView 6), so the exporting of functions from the DLL is still correct.
• The EXE's that also rely on the DLL run without errors under both Windows XP and Windows 10, so the DLL entry points are not incompatible with the operating systems.
• The LabView "Display Exported Functions" tool clearly reports the function names are visible to LabView in both Windows XP and Windows 10.
• DepencyWalker does not show any missing decencies for the DLL.
• When I go back to a version of the DLL compiled in Visual Studio 2013, there are no errors in Windows XP anymore.

Why would the same version of the DLL and same version of LabView work just fine in Windows 10, but have "Function not found in library" errors in Windows XP?

Why would recompiling the DLL in Visual Studio 2017 vs 2013 change how LabView sees the available functions from within Windows XP?

Anyone else encountered anything like this or have a potential solution?

[rolfk]

Most likely you need to install the according Microsoft Visual 2017 C Runtime library. When you build an executable it may contain that runtime in its private dependencies and when the DLL is loaded Windows can resolve the dependencies to this runtime library internally with the C runtime used by your executable.

LabVIEW was compiled with a different version of Visual C and therefore the DLL can't be resolved to those C runtime functions. Each Visual C version uses its own C runtime library. Installing the C Runtime library for Visual C 2017 on your XP machine should resolve that, but you may be in an unsupported area there as I don't think Microsoft supports Windows XP in any form by any of the Visual C compilers that were released after they discontinued XP support.

[NathanD@Triumph]

The Microsoft Visual 2017 C Runtime IS installed on the XP machines. I get completely different errors if I try to run without the runtime installed - it is very apparent when it is unable to resolve the dependencies.

These are errors that occur before the LabView vi's are even allowed to run. The error message "function not found in library" implies that LabView is unable to locate or match the named entry points for the functions within the DLL. However, when I run the "Get DLL Exports.vi" supplied by NI, it clearly shows that it can see the function names within the DLL. All of the rest of my applications that link to this DLL are finding the entry points without any issues as well. And when running the same DLL and same version of LabView on a Windows 10 machine, everything works just fine. I'm still confused as to why LabView can't seem to find the function names within the DLL only when running in Windows XP.

[rolfk]

That error message is unfortunately not very specific as to the error why it can't reference the function. The Get DLL Exports.vi function only walks the export table in the DLL and lists all entries using LoadLibraryEx(path, LOAD_LIBRARY_AS_DATAFILE)., it does NOT attempt to load the library for execution using normal LoadLibrary().

In order for LabVIEW to link to a DLL for execution of the functions it does need to use the normal LoadLibrary() function and that function fails when any of the dependencies can not be resolved. When LoadLibrary() fails, LabVIEW simply informs you that it could not load the function XYX from the DLL, without trying to guess if the function itself is not present.

Unless you use the option to specify the Library path on the diagram and pass it to the node, LabVIEW will LoadLibrary() the specified library at time of loading the VI that contains the Call Library Node and simply invoke the function at runtime. LoadLibrary() is an expensive function and calling it each time the Call Library Node gets executed would be a waste of performance.

[NathanD@Triumph]

I thought I replied to this the other day, but I must have missed a step when posting.

Thank you for the additional information. That helps me understand what is going on a little better.

---

@rolfk wrote:

Unless you use the option to specify the Library path on the diagram and pass it to the node

---

If I understand this correctly, it implies that I could add something to my vi that would either: a) force full evaluation of dependencies at design time; or b) delay evaluation of function names until runtime when the dependencies would be fully evaluated. If either of these are the case, I could potentially find the offending resource (or lack of resource) and fix it. Are my interpretations/assumptions correct here? If so, would you be kind enough to point me down the right path to give this a try?

Thank you

[rolfk]

Simply check the checkbox in the Call Library Node configuration function to pass the library name from the diagram. This enables an extra path input on the Call Library Node that will let you specify at runtime the path to the shared library to try to load the function from.

But!!! That will not help you specify where to look for secondary dependencies of that shared library.

And since now the library is not specified in the Call Library Node configuration at edit time, the App Builder does not know anymore which DLL you want to use, but instead you have to make sure that you add the library yourself to the build specification as always included file and make sure that you pass in the right path to that DLL at runtime to the location your application installer put the DLL in.

Basically it complicates building an executable in exchange for the advantage to let you specify the path to the DLL at runtime, but it will do absolutely nothing to let you specify where Windows should look for further DLL dependencies of your DLL.

[NathanD@Triumph]

OK, I think I can do something with that information. Although maybe I should clarify, I'm not building my test vi's into exe's. I'm simply running them within the LabView environment. As things stand now, I can't even get to the point of being able to run the vi to attempt loading the DLL or dependencies. When I load the vi, the icon on the Run button is a broken grey'd-out arrow. Clicking on it just brings up the list of all the functions it cannot "find".

I've tried other experiments where I've taken a machine that is working and removed DLLs that my main DLL is dependent upon.  In that case, the vi loads just fine and will attempt to run. It pops up the dependency errors at runtime, but it still able to correctly "find" the functions within my DLL at design time.  This error on Windows XP seems to be something different than just a missing dependency.

You wrote earlier "I don't think Microsoft supports Windows XP in any form by any of the Visual C compilers that were released after they discontinued XP support". However, VS2017 still has an explicit setting for compiling with XP compatibility (which I definitely have selected in my DLL build). My DLL and all my MFC exe's compiled in VS2017 work just fine on these XP machines.

I'm still stuck on the fact that my DLL works perfectly fine with LabView 6 on Windows 10, but fails to find the functions on Windows XP. I would think that if it's an issue with the older LabView version not being able to work with the newer C runtimes, it would be even worse in Win10.

still confused...