Error 8 occurred at Invoke Node in AB_EXE.lvclass:Build.vi->AB_Build.lvclass:Bui

[CarloLo]

During software build to make exe file, I got the following error message:

Error 8 occurred at Invoke Node in AB_EXE.lvclass:Build.vi->AB_Build.lvclass:Build_from_Wizard.vi->AB_UI_FRAMEWORK.vi->AB_Item_OnDoProperties.vi->AB_Item_OnDoProperties.vi.ProxyCaller

Possible reason(s):

LabVIEW:  File permission error. You do not have the correct permissions for the file.
=========================
NI-488:  DMA hardware error detected.

Method Name: Build:Application

The vi was working fine before the build. It just access some text files and creates some excel files. No hardware is involved. See if anybody know how to solve this problem. Thanks.

[Devin_K]

CarloLo,

What version of LabVIEW are you using?  Do you get this error with any application you try to build, or just with this particular project?  In your build specifications, did you keep the default settings or make any changes?  Try creating a new build specification with the default values and see if the error persists.

Have a look at the following discussion forum threads from users with similar problems, and see if any of their solutions work for you:
Error 8 occurred when building an executable due to file permission error?
App Builder Error 8

[CarloLo]

Verified that the application has to be closed before the next version application can be built. Thank you very much!

[Ryan_G_EE]

I am using LabVIEW 2014 and have been getting this error randomly, but fairly consistently on a recent build. I searched all over and could not find a solution that worked. However, just through trial and error I discovered that the problem is related to SSE2 Optimization in the Advanced properties window. I can consistently cause this error by enabling this feature and consistently compile successfully when it is disabled. Try turning this feature off and see if it solves the problem.

...UPDATE: After closing and re-opening LabVIEW this error came back, and did not seem to be affected by the SSE2 option. Not that it isn't related, but perhaps not the silver bullet I thought it was.

I also got the error to go away sometimes when I compiled the EXE while the main program VI was open, whereas it gave the error most of the time when no VIs were open...again, nothing seems to consistently solve the problem...there is definitely some kind of bug in the appllication builder, and it seems like there are a lot of people that have been struggling with this for a long time (as far back as LV 8)...hopefully NI eventually finds this bug and squashes it!..although, I doubt that anybody at NI is even looking for it...

[mikeporter]

Are you using any external files? DLLs, etc. Can you build parts of your application to see what part is causing the trouble? Is there anything noteworthy about the application or its architecture? What kind of computer are you doing the build on? OS?

Mike...

[mikeporter]

Are there any disable structures or conditional compilation structures? Object oriented, real time, or FPGA? How large is the codebase? Was it originally written in an earlier version?

Mike...

[Ryan_G_EE]

It's pretty small code...just a state machine with a dozen or so states that configures, reads and displays data from an Agilent Data Acquisition System. No DLLs or external files (other than relatively small Sub VIs, three global variables and a few TypeDefs). There are a few small diagram disable structures (just commenting out small portions of code)...but Ive used those in other code before and not had any trouble...

It was written in an earlier version, (2013 I think), although some of the Agilent VIs were written in a much older version and then automatically upconverted to 2014. I had similar issues back then (2013), but LV 2014 converted it when I opened it up and it compiled fine for a while, so I assumed that LV fixed a bug...then the problem started coming back. I haven't tried breaking it up and compiling SubVIs yet...may try that once I get some free time. For now, it is working, it just requires consulting a shaman and performing a yet unknown ritual before compiling the EXE...did I mention that the code RUNS just fine in development mode? It also runs fine once compiled. It's just compiling it that's problematic.

[mikeporter]

Try doing a forced recompile. Ctrl shift R.

Mike...

[Ryan_G_EE]

At what screen? Ctrl-Shift-R doesn't seem to do anything at eather the Project Explorer window, nor in my main VI. Also, it's compiling now...so no idea whether a forced recompile would fix the issue or not. It's aggrivating how unpredictable the compiler issue is...sometimes it works, sometimes it doesn't...

-R

[mikeporter]

I'm sorry, having senior moment. S.b. on the main vi, hold down Ctrl and shift and click run.

Also do you have the VIs set to separate the source code?

Mike...