Error 7 "File Not Found" from Call Library Function Node despite DLL file existing at input path

[jmorris]

Hello all you helpful forum-goers!

I'm getting an error 7 "File Not Found" from a Call Library Function Node, despite the fact that I can see via probe that the wire value for the input Path is correct, and I have triple-checked that the DLL file I want to call is at that file system location.

For context, I am running an NI Hypervisor system using LabVIEW 2012 with Real-Time and FPGA modules.  The code is running on the real-time side, and I have it set up to build a path to one of multiple different engine model DLLs when the selected engine model changes elsewhere in the code, and to maintain the existing DLL path otherwise.

I have verified the DLL files are at the correct path on the real-time file system, e.g. "c:\ni-rt\startup\data\ExtraSpecial_EngineModelBoosted.dll".  I have verified via probes that the path gets rebuilt correctly when the engine model changes.

The system was working correctly at the start of my project, and I am not sure what changed such that it is not working now.  I did add support for a new engine model including putting a new DLL in the above-referenced "data" folder, but this code did not need to be updated for that.  I have verified that all of the Call Library Function Node configuration options are the same as before I started:

• "Specify path on diagram" is checked
• "Library name or path" still points at a DLL that doesn't exist anymore, but I assume was originally used to set up the function name
• "Function name" still has the same string that starts with a question mark, followed by the function name, "@@YAXPAU", the name of the input structure, "@@PAU", the name of the output structure, and finally "@@@Z".  Full disclosure, I'm not sure what all of that means, especially because I noticed if I select an existing engine model DLL, the available functions change to be just the function name.
• "Run in any thread" is selected (vs. Run in UI thread)
• "C" is selected under "Calling convention" (vs. "stdcall (WINAPI)")
• Return type is void
• The input and output parameters are "Adapt to Type", not Constant, and "Pointers to Handles"
• Default error checking

My searches on this topic mostly turned up suggestions about making sure the development environment matches the deployment environment, but that isn't applicable in this case because I am setting up a computer / device that I will then give to the customer, so there is only the one environment.

I do have in the real-time executable build specification the engine model DLLs in the "Always Included" section of the "Source Files" properties, the "data" folder referenced above set as a support directory in the Destinations properties, and those DLLs set to deploy to that support directory, but I'm not sure how much that matters because I am also placing the DLLs directly into that "data" folder in the real-time file directory via FTP using Windows Explorer.  Do those settings mean that if I had not manually placed them myself, LabVIEW would do so when I deploy the real-time executable?  And since I did do so manually, does it matter that those settings are set that way?

Below is a picture of the relevant section of code, for what it is worth.  If anyone has any ideas as to why I'm getting an error 7 "File Not Found", I'd really appreciate your help!  I've been banging my head on this one for a while.

Thanks for your time!

Dynamically building path input to Call Library Function Node

[rolfk]

So this is executing in the LabVIEW realtime system? It then does use in fact Pharlap ETS as operating system, doesn't it?

That is not a real Windows system and comes with a number of limitations as to what Win32 APIs are supported.

What Visual Studio version are you using to create those DLLs?

[jmorris]

Good morning Rolf,

Yes, this is executing in the LabVIEW real-time system, which to my knowledge means it is running Phar Lap ETS 13.1.  I can confirm that if you point me at where to look on the system.

The DLL was compiled using Microsoft Visual Studio 6.0 on Windows XP, with I some version of the Visual FORTRAN plug-in (I can get more specific details in a little bit).  This is unfortunately the only system we have that will compile the original FORTRAN code of the engine model (with a wrapper written in C).

Do you know what file dependencies might be introduced that I can check for?  It did not occur to me that the missing file would be one that the main DLL is trying to call, but that makes sense.

Thank you for your time and any other suggestions or ideas you might have!

-Joe

[rolfk]

Visual Studio 6 uses the standard msvcrt.dll which was also included in the Pharlap ETS export list (with the exception of some private exports from the Microsoft runtime). So that part should be fine. With newer Visual Studio versions you run into the problem that each of them uses its own msvcrXX.dll. But you can't just go and install the standard Microsoft redistributable C runtime installer on Pharlap since they depend on private Windows kernel APIs that Microsoft never (or only after the fact) documented and where therefore not available in Pharlap ETS.

But Fortran is of course throwing a huge potential of trouble in here. Those Fortran DLLs depend themselves on other Microsoft Fortran Runtime libraries which may have an entire bunch of potential compatibility problems of their own in respect to being able to load on Pharlap ETS. Do those Fortran libraries have an option to be compiled as self contained similar to what you can do for C DLLs? (Selecting the Multithreading Runtime Support instead of Multithreading DLL Support in the compile options). This will for the C DLL in fact include the C Runtime Library in the DLL (and make it bigger of course) but often circumvent the problem of having to install Visual Studio Version specific runtime libraries in every target system. It's still no guarantee that it would run on Pharlap ETS since Microsoft also likes to make use of the newest and greatest Win32 APIs in those runtime functions and the Pharlap ETS API is really at about the state of Windows NT4/2000 and any newer APIs introduced (or documented) after that are almost never included. Pharlap/Ardence/ZeroInterval/NI, in a few select cases added (stubbed) support for a few later Win32 APIs but they are few and far in between.

Generally you want to check all the DLLs with some Dependency Checker like tool (for instance this) to see what dependencies each has. Also NI has a download page where they provide special tools that you can point at a DLL and it will tell you if it references APIs that the according LabVIEW Realtime Pharlap ETS kernel doesn't support. This tool is different for each LabVIEW version. It may be a good idea to archive this page somewhere else as with the discontinuation of LabVIEW Realtime Pharlap ETS, this page is bound to disappear at some point when someone at NI cleans up the website.

[jmorris]

Hi Rolf,

Great idea, thank you!  I will make use of that dependency checker ASAP and see what I can see.

-Joe

[jmorris]

Hi again Rolf,

According to the DLL Checker 2012 from the page you linked, the newly added engine model DLL has a dependency on DFORRTD.DLL, which I don’t have on the target system, plus some unsupported calls itself, so that certainly makes sense that it wouldn’t be working. I will look into compile options to fix that.

However, the previously existing engine model DLLs depend on DFORRT.DLL, which is already in the same folder as the engine model DLLs on the target system, and neither it nor the older engine model DLLs have any bad calls (and only DFORRT has any stubbed calls).  This makes sense as the older engine models used to work. And yet now they do not.

Any further suggestions for things I can look into as to why the older engine models are also giving the error 7?

Thanks again for your help!

-Joe

[rolfk]

Sounds like you are not using the same version of the Fortran compiler than what was used back then for the older engine model DLLs. It's definitely not something LabVIEW has any way to influence and you need to check at the compiler side.

Is it the same system and version you used to generate the old engine models? Any (unnoticed) updates since then?

[jmorris]

Hi Rolf,

I agree, and I am looking into that, although it is difficult since the last time we added an engine model was in 2015 and we didn't keep amazing records of the environment we used.

Unfortunately, none of that explains why the existing engine models from our configuration management system would stop working.  I confirmed that the DFORRT.DLL file from our configuration management system is on the real-time side's file system, in the same folder as the engine model DLLs (which is where it always was, if I'm reading our configuration correctly).  I even deleted it and re-added it in case it had gotten corrupt or left open by another process or something, although our multiple restarts would have fixed the latter.

Is there any way I can get more detail on what file or function call is triggering the missing file error, using a dummy VI / process call of some sort maybe?

Thank you for your continuing patience and assistance!

-Joe

[rolfk · Accepted solution]

Well, are you sure it is using the DFORRT.DLL file you think it is using????????

I'm not sure about the exact standard locations the Pharlap ETS system will look for dependent libraries when trying to load DLLs, but I'm pretty sure that the directory where your primary DLL is located is in no ways privileged by Pharlap ETS in any way to any other directory on the system. And it won't search the whole disk for a DLL that is also for sure.

So your DFORRT.DLL that you see in that directory may just be sitting there being pretty, and not having any functionality whatsoever. Instead on the system where it worked, someone had probably figured out that this DLL should instead be copied into the C:\Windows\System directory or whatever is the equivalent on Pharlap (I don't have a system handy to check) to make it work!

[jmorris]

That was it, Rolf, thank you!  The DFORRT.DLL (not case-sensitive, by the way, which was another thing I checked) file needed to be put into the "C:\ni-rt\system" folder on the real-time side, rather than in the same folder as the engine model DLL.  That was not correctly documented in our installation / setup process, and the file in that location must have been lost at some point during a system restore.

The new engine model having extra dependencies is something we are actively addressing by paring down its function calls to match the older models, but now that the older engine model DLLs are working again I am confident that we can get the whole system working.

Thank you again for your patience, insights, and suggestions!  You are truly a LabVIEW Champion. 😊

-Joe