From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Built application doesn't run when installed in Program files (x86)

Solved!
Go to solution

I'm using Labview 2018 on Windows 10. I have an application which doesn't have any dependencies other than some DLLs, which are included with the application. I'm building an executable (which includes those DLLs), in the same folder as the source code and it runs fine. I'm building an installer and use it to install the application in program files (x86) and it gives me the following error:

 

image.png

If I copy the executable, from the folder with the source code over the installation in program files (x86), I get the same error. If I copy the installation from program files (x86) over the executable in the folder with the source code, it works perfectly.

 

I tried the following without any success:

  1. unlocking all files in the intaller specifications page
  2. running the application as administrator
  3. installing the application as administrator
  4. disabling antivirus
  5. restarting PC
  6. installing the application on drive 😧

It must be a dependency problem but it must be due to something blocking the access to that dependency whent the application is in certain locations. If simply copying the executable into program files (x86), it throws the same error. Has anybody encoutered this problem before? I've built and deployed many applications but never seen this one.

0 Kudos
Message 1 of 7
(2,612 Views)

Some random thoughts:

Are you using 64-bit LabVIEW?

Are the DLLs 64-bit?


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 2 of 7
(2,572 Views)

Are in the folder where your DLL is located in the build destination where the application works other DLLs located?

Rolf Kalbermatter
My Blog
0 Kudos
Message 3 of 7
(2,553 Views)

I'm using Labview 32 bit and the DLLs are 32 bit as well. All the DLLs are within the installation folder (in a separate sub-folder) and there are no other DLLs (which are not dependencies of the application).

0 Kudos
Message 4 of 7
(2,498 Views)

Where I said:

I tried the following without any success:

     ...

     6. installing the application on drive 😦

 

it should have been: installing the application on drive D

0 Kudos
Message 5 of 7
(2,496 Views)

Right, I managed to make a bit of progress here. My code also depends on a lot of functionality which I have in separate compiled labview libraries (.lvlibp). These libraries are all included with the executable.

 

One of these functionalities is an XControl placed in the VI to which the error refers, which is dynamically called. I managed to partly debug the executable and figure out that the probelm is that the XControl cannot be loaded when the executable is in Program files (x86). If a replace the XControl with a regular control, everything runs fine.

 

Now the problem is why can it not load the XControl when the executable is located in Program files (x86)?

0 Kudos
Message 6 of 7
(2,434 Views)
Solution
Accepted by Lexandros

I managed solve the problem. I found a similar issue in another forum post which described that Labview has a bug. This is what happens:

 

When you have an XControl in a library (mine was in a .lvlibp) and this xcontrol is used by a VI (which is outside of the library) and you build everything in an executable, Labview doesn't load the library with the xcontrol correctly. So the VI sees the xcontrol as broken.

 

The solution is to ensure that the xcontrol library is loaded before the VI which contains the xcontrol needs to run. This can be done by placing a static VI reference to the xcontrol Facade.vi, on the block diagram of any VI which is loaded into memory before the VI which contains the xcontrol.

 

Hopefully this is clear.

Message 7 of 7
(2,414 Views)