LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Application Builder can't build exe. Error 8 occurred at AB_EXE.lvclass:Build.vi -> AB_Build.lvclass:Build_from_Wizard.vi

Solved!
Go to solution

I bought a new laptop from Dell (Windows 10 Pro) and installed LV 2015 (32 bit) on it. I copied my project files over and tried to build the exe and got error 8. After much searching for an answer, I created a minimal test project with just a single blank vi and a basic exe build spec to reproduce the error with. Every time I try to build, I get the same error 8: 

 

An error occurred while building the application. Either you do not have the correct permissions to create the application at the specified location or the application is in use.

Invoke Node in AB_Engine_Build_Method_Wrapper.vi->AB_EXE.lvclass:Build.vi->AB_Build.lvclass:Build_from_Wizard.vi->AB_UI_Frmwk_Build.lvclass:Build.vi->AB_UI_FRAMEWORK.vi->AB_Item_OnDoProperties.vi->AB_Item_OnDoProperties.vi.ProxyCaller
<APPEND>
Method Name: <b>Build:Application</b>

Error 8 occurred at AB_EXE.lvclass:Build.vi -> AB_Build.lvclass:Build_from_Wizard.vi

Possible reason(s):

LabVIEW: File permission error. You do not have the correct permissions for the file.

 

 

I can't think of any permissions problems I might have. I of course have full administrator privileges on the machine. 

 

I saw other posts (like this one) that talk about having Windows Explorer open to the build path when trying to build and getting this error. I have made double sure that I do not have ANY Windows Explorer windows open when trying to build. There was some mention in one of the posts that maybe LabVIEW's Current Directory is set to the build folder, but I don't quite follow what that means, or why that would be happening when it doesn't usually prevent me from building on other machines.

 

I tried the steps in this KB, but no help. 

 

 

Interestingly, I created a virtual machine (Win 10) for a different project and installed LV 2015 32 bit in the VM, and all my applications build just fine in the VM. But on my physical machine's OS, I get this error 8 for every application I try to build. 

 

I tried repairing LabVIEW, and also I tried uninstalling an reinstalling LabVIEW. Neither made the error fully go away. After repairing, the project successfully built one time. But subsequent attempts to build fail with the same error.

 

See the attached test project and its build log.

 

Thanks,

 

Nathan Scharfe

CLD

Nathan Scharfe
Certified LabVIEW Architect
Download All
0 Kudos
Message 1 of 16
(8,467 Views)

I've gotten build errors similar to this. What has helped me is to delete the folder that the application builder creates in windows explorer, and to close the windows explorer windows (particularly any that are looking at the location that you are writing to). Then I attempt to build again. Even this is not foolproof, and I have to try a couple of times before it builds without error.

Message 2 of 16
(8,456 Views)

Thank you for your reply. Yes, I tried what you suggested of deleting the build folder, but I still get the same error no matter how many times I try to build. I've closed and reopened LV, I've restarted my computer as well, but even when I deleted the build folder it still gets this error. 

 

And as I mentioned I made triple sure that I have NO Windows Explorer windows open at all. 

 

Thanks,

 

Nathan Scharfe

CLD

Nathan Scharfe
Certified LabVIEW Architect
0 Kudos
Message 3 of 16
(8,450 Views)

Hi Nathan,

 

Have you tried right-clicking LabVIEW to "Run as Administrator"?  Also, have you checked to see what the permissons are for the folder that you are trying to send the executable to? You could also try checking to see which files are in the project to be sure only the VIs you need are inside it. Try rebuilding the project with only the files that you need and let the compiler link the libraries as needed.   

Regards,

Jake H
Applications Engineer
Message 4 of 16
(8,413 Views)
With the last few versions of Windows, being an "administrator" doesn't mean as much as it once did. You can still get permission errors -- double check everything just to be sure.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
Message 5 of 16
(8,392 Views)

As far as I can tell, Windows 10 no longer has a problem if Windows Explorer is open to the build folder, so it's probably not that.

 

I'm assuming the log file is one that was created by configuring logging in the build settings. I have no experience with reading these files, but if I'm understanding it correctly, it doesn't even try to build and immediately returns the error. With the Explorer block, what would happen is that the AB would go through the whole build process and then only fail when attempting to convert the generated folder to a single file (presumably because Explorer is doing some kind of indexing), so that indicates you may really have permission issues.

 

Besides what the others said, there's an INI key you can add which enables logging (apparently it's NI_Appbuilder_logging=TRUE), which I think is more detailed than the standard checkbox, although I'm not sure. I would suggest seeing if that gives you more info on exactly when the problem happens (although based on the timestamp it appears to happen immediately).


___________________
Try to take over the world!
Message 6 of 16
(8,338 Views)

Thank you to Jake, Mike, and tst for your replies and helpful suggestions. 

 

I have been out for the past few days and now I can respond to your replies:

 

1. Yes, I have tried "Run as Administrator." No help.

2. As for the permissions of the folder, I have "Full Control" permissions. (see the attached screenshot of the permissions). I have also tried overriding the inherited permissions of the folder to force full control for my username, but that didn't help.

3. The only VI in the project is a single blank VI that does nothing. There are no other dependencies, because this is a simple test project that I created just to troubleshoot this problem. 

4. I enabled the INI key that tst suggested. See the more detailed build log attached (test test build log.txt). From what I can tell from the log, it looks like the build proceeds normally until the very end where it fails just after AB_L Close Refs and before AB_L CloseBuild after having done just about everything. 

 

I have re-created my test project several times in various different locations on my computer, and I still have this problem no matter where I put it (so far). 

 

One more thing to note: every once in a while (seemingly randomly, maybe 1 in 20 times), the build is successful. I saved the detailed build log one time when it randomly happened to build successfully and it's attached below (random_successful_build.txt). 

 

Thanks for your help!

Nathan Scharfe
Certified LabVIEW Architect
0 Kudos
Message 7 of 16
(8,298 Views)
Solution
Accepted by topic author nathanscharfe

My best guess is that some external process is using the folder and not letting you write there. The most likely candidates are anti-virus software or an indexing service of some kind. I'm guessing that it occasionally succeeds simply because it's a race condition and in those cases the blocking party didn't get in yet or is already done.

 

You could try building to a network drive, where such forces are less likely to be able to do the lock or you could try finding software which shows you which software has open handles to a folder and monitor that to find the offender. I seem to remember that both Process Explorer and SIW show this, but this is far from my area of expertise.


___________________
Try to take over the world!
Message 8 of 16
(8,278 Views)

tst,

 

I wish I could give you multiple kudos for this post! I was wasting so much time re-trying builds, but it looks like building somewhere on the network has fixed it!

0 Kudos
Message 9 of 16
(8,231 Views)

I am glad that tst's answer has helped you too gregoryj. I also tried building to a network drive, and it does indeed succeed every time. 

 

tst also mentioned trying to use Process Explorer to show which software has open handles to the folder. I tried this, but couldn't find any program with handles open to the folder. 

 

While I would ideally like to figure out what the problem is that prevents me from building on my local machine, for now using the network drive trick is sufficient to get me by. Thankfully I do most of my development in virtual machines where I haven't seen this issue. 

 

I'm going to go ahead and mark this one as solved.

 

Thanks very much for your help!

Nathan Scharfe
Certified LabVIEW Architect
0 Kudos
Message 10 of 16
(8,224 Views)