Error 7148 Unable to load dependent DLL only in deployment

[SamSydney]

Hi All,

I have created an executable that is meant to communicate via UDP to an instrument on a local network. The communication is handled though a DLL built using VC++ 2013. The topography is as follows:

LabVIEW Call Library Function Node calls TT.dll

TT.dll is dependent on brt.dll.

We have found that on the host PC this functions correctly in both the dev environment and built executable (though we do intermittently receive error 7171 and error 7156, it seems like retrying a couple times will connect).

When we deploy to another PC, we get error 7148 at the first CLFN which references brt.dll. The source code runs just fine in the dev environment.

Sniffing with Wireshark has indicated that when we get the 7148 error, there is no network communication with the instrument.

I currently have both DLLs in an lvlib within the project. Both files are physically located in the same directory as the lvlib.

In the executable build properties, I have them set as Always Included.

Is there a specific way I should include the defendant DLLs?

Any indication on why this would fail on a target only?

Also, since it opens TT.dll, it indicates to me that there isn't an issue with the correct Microsoft Visual C++ Redistributable being installed.

One thing to note is that brt.dll has no callers in the project. I believe this is expected, since the only thing that calls brt.dll is TT.dll, which the LabVIEW project can't tell.

Many thanks for your ideas!

Regards,

Samuel Sydney

SW:

LabVIEW 2016 SP1 x86

Visual C++ 2013 x86

Windows 10 64bit

[aputman]

The DLL is found in the dev environment because it is loaded in memory with the project.  And even when you run an EXE on the dev environment, it is found because you most likely still have the project open and loaded in memory.  My guess is that if Labview is shut down and you try to run the EXE that it will also fail on the dev computer.

The DLL should not be Always Included in the EXE.  Try saving it to a support directory when compiling the EXE and make sure the Call Library function has an appropriate relative path to the DLL in the support directory.  You might want to drop a path indicator on your FP where you can check that the path is what you expect it to be.

[protocoled]

 Hi,

As aputman mentioned, you should not always include the DLL in the application. In addition to his advice, it seems likely that the errors you are receiving on your development machine are not related to the errors on your deployment machine. I found this article which may be helpful to read through:

http://digital.ni.com/public.nsf/allkb/862567530005F09C862565C50068363D

[Great-Britton]

Hey, 

It's likely that your executable doesn't know how to find either the DLL, or dependencies of your DLL.  You can add a line into the DLL for the config file for your DLL, or the executable to tell it where to look.

The config file should be named something like  myapp.exe.config or mylibrary.dll.config, and the contents would be something like:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
            <probing privatePath="relative path from dll or exe to dependencies" />
        </assemblyBinding>
    </runtime>
</configuration>

[rolfk]

Did you create both DLLs in Visual C 2013?

Did you select the project to link with the static C runtime library or the dynamic runtime library?

Also did you distribute the Release or Debug build of your DLLs? The debug built can normally only run on a computer where the Visual C Debug runtime library installed, which is installed with Visual C but there are no redistributables of that to install on other machines and neither is Microsoft giving out licenses to do that legally.

If you selected the dynamic runtime library did you install the C runtime library redistributable installer for Visual C 2013 on the deployment machine?

And you should probably make those DLLs install into the same directory where your LabVIEW built exe is, then Windows will find them itself.