LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Get Error 6 about 50% of time when building Application

Have any of the suggestions we've made seemed to either reduce the occurrence of the problem or increase it?  We are still trying to figure out exactly what is marking the file as reserved when we try to delete.  If any of you have a particular project that seems to reproduce the problem more frequently please let me know via this forum or private message.

 

Has anyone tried to disable the Windows 7 indexing that I linked above?

Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
0 Kudos
Message 31 of 54
(2,087 Views)

 


@Jon S. wrote:

Have any of the suggestions we've made seemed to either reduce the occurrence of the problem or increase it?  We are still trying to figure out exactly what is marking the file as reserved when we try to delete.  If any of you have a particular project that seems to reproduce the problem more frequently please let me know via this forum or private message.

 

Has anyone tried to disable the Windows 7 indexing that I linked above?


I had this problem and it went away when I moved to c:\builds. I thought it was because the pathnames were too long. Maybe it was because this is not an indexed location? I will turn on indexing for that location and post back here if I see the problems again.

 

=====================
LabVIEW 2012


0 Kudos
Message 32 of 54
(2,081 Views)

yup, this did the trick for me. Now building into c:\b Smiley Happy

 

The filename was getting way too long as it was referring to c:\user\etc etc etc

0 Kudos
Message 33 of 54
(2,064 Views)

There must be multiple situations that cause this. hfettig said that making the path shorter did not solve his issue. But it did solve mine and yours.

=====================
LabVIEW 2012


0 Kudos
Message 34 of 54
(2,058 Views)

I just stumbled onto the same problem with LabView 2010 SP1 running on XP Pro SP3. Nothing seemed to help until I noticed that my LLB did not have a designated top level VI. Once I designated my top level VI it built with no hicup. This might be helpful to others getting consitent Error 6 on building applications.

0 Kudos
Message 35 of 54
(2,004 Views)

Shortening the path solved my build problem with this error too:manvery-happy:

 

I tend to work off a network drive with a several folder paths mainly for backups but now i will work local and auto backup to the network drive

0 Kudos
Message 36 of 54
(1,968 Views)

Hello Everyone,


First off I want to be clear that there are people talking about two completely different problems in this thread.  Both of them produce an Error 6 but for two entirely different reasons.  The build path being too long issue is described in detail from this KnowledgeBase (Error Code 6 Occurred at AB_Source_VI…).  The original poster and a few others are describing an intermittent error during build process (Error 6 Occurred at Delete in AB_Engine_Delete_Internal_Files.vi…).  I will be responding to the latter.


Thanks to one of our customers I received a project where I could reproduce the Error 6 Occurred at Delete build error.  We could only reproduce this on some of our machines, mine being one of them (A fast QuadCore running Windows 7 64-bit).  Based on some of our assumptions I used Procmon and some filters to monitor any process that was touching our build directory that could be reserving the files when we tried to lock them.  When I did this I found several different processes that were accessing that directory: Windows 7 Search Indexer, NI DataFinder, McAfee Antivirus and another search indexer I installed called Search Everything.  Using the process of elimination I narrowed down the cause of this problem to be caused by my Search Everything program.  I could only reproduce the problem with it enabled.


This leads us back to what we had suggested in some of the original posts.  You need to ensure that you do not have an indexing program or others that are accessing this folder.  If you are unsure or don't believe that you are running a program of this sort I would run Process Monitor and filter it to see all activity in the build directory.  Try disabling the programs that are also using that folder to see if you can narrow down what is causing the problem.  Most indexing programs will allow you to exclude certain directories so you can continue to run these programs without hitting the build error.


We will be adding retry logic into our code to try and avoid this error in the future.

Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
Message 37 of 54
(1,956 Views)

Hi,

 

Took some time to figure our process monitor. 

 

When I get failures the process BuildAppHelper.exe fails to run.  When my build is good this process has several entries in the process monitor log.

 

No windows cache, no Google desktop, no other apps other than explorer.exe.

 

Still running about 50% error 6 fail.

 

Mark

-------
Mark Ramsdale
-------
0 Kudos
Message 38 of 54
(1,921 Views)

For my case when I have a error 6 build the process monitor shows no processes from "BuildAppHelper.exe " 

 

 

 

For the most part the builds all work now. 

 

I'm going to turn on Google desktop and Windows ~Indexing~ to see what extent they may be interfereing.

 

 

 

 

 

-------
Mark Ramsdale
-------
0 Kudos
Message 39 of 54
(1,889 Views)

Hello Mark,

 

I've attached a picture of what my filters look like in process monitor.  I removed all of the automatically included ones as well.

 

The BuildAppHelper.exe is a process that helps with the memory management of the build process.  It is spawned by app builder after where the error is occurring.  Because app builder uses the standard error functionality we don't launch this process if we receive an error before it.  Because of this we expect that the executable wouldn't show up in the logs if we received an error.

 

Regards,

Jon S.
National Instruments
LabVIEW NXG Product Owner
0 Kudos
Message 40 of 54
(1,886 Views)