Showing results for 
Search instead for 
Did you mean: 

dll not working on deployed computer

Go to solution



I am working on a VI to run a night vision camera.

My development PC is win 7 and I am running LabVIEW 2014.

My deployment machine is a Microsoft Surface Tablet on Win 10.


The Camera driver software is Pleora, I am also useing some IMAQ functions.


The VI and the exe that I built run just fine on the development Machine, the display is working and running between 30 and 60 frames per sec. Color at 1280 x 1024.  (a lot of PC resources)

I have a consloe command window that also works on the development PC.


It is not running on the deployment device, ( Microsoft Surface Tablet on Win 10.)


My first issues were related to the location of 3 .dll files.

they are:



eBUS_C_SDK.dll - (this is the one from Pleora)


The exe would query me for the location.  I solved this by adding them to the folder where the exe file was stored.  A temp workaround.


When the exe launched I get a "Missing External Function" message with the induvidual sub VI that is calling a specific dll.  15 in all.

The front panel comes up as I would expect, but I get the message on top of it.


 I have installed and re installed the cam drivers on the surface.

I have verified that the surface has the full version of the RTE.


Thanks in advance;





Michael C. Nedrow
0 Kudos
Message 1 of 9

You probably need to install the NI IMAQ and NI Vision Runtime on the target PC. If you create an installer, it will select the components automatically that your software uses on the 'additional installers' page of the installer build specification.


The missing eBus/Pleora DLL is because it is probably expecting you to have the installed the drivers for that device too (check your Call Library function node for where it is looking for the DLL - if it's System32 or something like that then that's where the driver installs the DLL to). If it's looking somewhere else (e.g. a non-system folder), you might be able to include the DLL as part of your executable build specification.

LabVIEW Champion, CLA, CLED, CTD
0 Kudos
Message 2 of 9

Now I really feel like a clown..........


I moved the eBUS dll to the system 32 folder.

I can see it with windows explorer.

LabVIEW does not see it when I go to one of the call lib nodes and try to configure and browse to the path. Even after a reboot.

What am I doing wrong?



And Thanks forthe help!





Michael C. Nedrow
0 Kudos
Message 3 of 9
I think if you specify just the DLL name, it will look for it in the system dll folders (e.g. System32 / SysWOW64)...and I think also the base directory of the executable. If it's just a standalone DLL, you can just put it as part of your executable build specification.

Not sure why it's not showing up with windows explorer, did you try changing it to show 'all files' in case the extension was messed up?

LabVIEW Champion, CLA, CLED, CTD
0 Kudos
Message 4 of 9

Two possible issues here:


1) System32 on a 64 bit Windows system is only for 64 bit applications. On a 32 bit application even if you point it to system32 explicitedly Windows will automagically redirect that path to SysWOW64.


2) Your Pleora DLL may not be self contained. It may depend on other DLLs either a specific MS C Runtime library version or other help DLLs from Pleora themselves. When secondary DLL dependencies can't be resolved by Windows when an application requests to load a DLL, it will simply fail the load without specifics about why the load failed. LabVIEW will inform you that it could not resolve the function into that DLL eventhough the DLL is obviously there and the function too.


Moving drivers of any sort to another system by copying a DLL to that system is something that may have worked 20 years ago but is definitely something that should not even be attempted nowadays. Use the proper installer from the manufacturer. If that doesn't work for some reasons on your target system then there is most likely a good reason for and copying DLL files on your own is in most cases just making a big mess.


And watch out what Surface Tablet you are using. You seem to have an x86 based version otherwise the LabVIEW exe wouldn't even be able to start up, but there are Surface Tablets out there which run Windows RT on an ARM CPU. That is a Windows version that can not run x86 compiled applications like what LabVIEW creates.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 5 of 9

Sam and Rolf,

First of all thank You.

The Surface is running an intel core (windows 10) I have other VIs that do not include vision functions running on it.


Here are my clues at the moment.

I used the LabVIEW widard to create all the call library function nodes and the wrappers. ( I am sure that I am verbalizeing that incorrectly)

I included the dll in the always included source files.

as an example, there is a sub VI called: PV Dev Close Serial

This VI seems to be fine on the development PC.

On the surface, when  I run the exe from the installer, I get the error message:

Missinf external function then the name of the dll eBUS_c_SDK.dll, then the name of the that I see in the function prototype box in the configure window of the node, PV Dev Close Serial Port@0:C in PV Dev Close Serial

Is there something I missed with the function prototype?  I was not aware of this when I built the wrappers.  (Or when I was doing the development at my desk.)




Michael C. Nedrow
0 Kudos
Message 6 of 9

Hi mcnedrow,


You'll need to have Vision Acquisition Software (VAS) activated on the computer you're deploying to. It's often recommended to purchase the Vision Development Run-Time Engine (VDM RTE) which includes a license for VAS for the same price as VAS alone. Below I've provided a link with more information regarding licensing with NI's Vision software.


I hope you find this information helpful!


Best Regards


Kale Woosley

0 Kudos
Message 7 of 9

I do have the NI vision runtime engine on the deployment machine.  (I have tripple checked)


The issue seems to be with the 3rd party DLL not being read, or read correctly.




Michael C. Nedrow
0 Kudos
Message 8 of 9
Accepted by mcnedrow


Thanks to:


Paul and Ren from the service request line The issue is identified and fixed.


Thank you both for your help today!

I just had a major breakthrough, Looking at the forum thread that Paul pointed me to I went in to each call Lib function node and changed them to specify the path on the block diagram, and added a application directory constant to each

Michael C. Nedrow
0 Kudos
Message 9 of 9