Application Builder File IO Errors: Reveal Which Path

[Mr._Jim]

Hello all,

This is an elaboration on a prior request by RavensFan:

When AppBuilder reports a file related error, such as error 8, could someone please provide a path?

I have no idea what's causing my file IO error, as I am running LabVIEW as a local admin and there should be nothing interfering with my path.

I can't probe a path wire in the AB method because the diagrams are understandably locked.

This is so frustrating.  No one likes to debug by guessing and it wastes a tremendous amount of time.

Thank you with my deepest respect to the AB team.

Jim

For example:

[DavidBoyd]

I'll have to "me, too!" tst's comments on this one.   My regular environment is 2011SP1, and my experience with AB success is very hit-or-miss - offhand I'd say that 30-40% of the time I invoke it, I get an error 8.  My workaround is to just... try it... again...  And I can confirm the behavior of having the target folder open in Windows Explorer making the odds of failure near 100%. (Around here, we colloquially refer to that issue as a "bashful" AB.)

My guess has always been that either Windows file indexing, my antivirus (McAfee VirusScan Enterprise), or less likely, backup (Autonomy), holds an open file handle that prevents the AB from completing a rename or delete operation at the conclusion of the build.  An abort/retry dialog would be very handy here, as described in the other IE post tst referred to.

Just wanted to add my experience, and by so doing, dilute the NI-bashing quotient.

Dave

[Mr._Jim]

Hi all, I was on vacation last week and am just now reading all of the replies.

tst, thanks for the input regarding Windows Explorer.  I wonder if the issue has something to do with the antivirus on the company laptop. I just changed jobs earlier this year and I'm running on a different setup now. (I'm stranded in a hotel with my personal laptop today, so I can't give you the exact antivirus we're using from memory) Seems odd that just an Explorer shell window would cause a permissions error by itself, though. There might well be some other program with sloppy file permission handling. Intuitively, it doesn't seem to me like an AB bug per se, but rather the AB's rather touchy handling of transient permissions issues caused by other applications. I'd imagine it's because these scenarios just weren't anticipated.

Dave B and MGiacomet, I concur that many times it seems like a crapshoot - on a bad day it does indeed seem like a 30-40% "bashful" AB rate. My build for this rather large application (2600 VIs, OO architecture) tends to take a few minutes, and the way I've been handling the down time while building is to run my builds on a separate PC. (Sort of like FPGA compiling, I guess : )

...and of course, you can probably tell that I never want to engage in "NI bashing," myself. I realize this is a tricky one because it's tough to reproduce myriad environments with lots of variables and weed out all the bugs related thereto.

How about this: if there aren't already retries in the app builder, what if there were a retry setting such that if file IO errors occur, AB should retry up to n times and then prompt the user for further action? (Don't retry the whole build, just the last part where saving the exe as a single file typically fails?) It seems to me that this might increase the odds of a successful build on a tempermental setup. If this seems like a decent idea, should I pitch it as a separate Idea Exchange thread?

Thanks again to everyone.

[AristosQueue (NI)]

Mr._Jim -- any guesses on how long a retry delay might be necessary? It's an open ended thing, but if we had some data points, we might figure out how long it takes some particular machines to unstick themselves and then use that delay.

[Mr._Jim]

Hmm... That's a really good question. 

Offhand, I'm not sure how one would easily ascertain the optimal delay, because I think it would depend on which meddling app is interfering with the build.

Thinking "aloud":

Based on some quick research, using Process Explorer (Sysinternals), the "Find Handle or DLL" function may accomplish this.  (Enter the suspected "locked" file in the search)

The trouble with this method is that there doesn't seem to be any easy way to continuously monitor the lock on the file.   Given enough time, I'm sure we could figure out a good way to determine this.

I suppose we could try something arbitrary like five or ten seconds?  (An eternity on most machines, I'd think)

Would a configurable delay make more sense, with a default of ten seconds?  A "one size fits all"  delay doesn't seem like a good long term approach.

[AristosQueue (NI)]

> Offhand, I'm not sure how one would easily ascertain the optimal delay,

> because I think it would depend on which meddling app is interfering

> with the build.Offhand, I'm not sure how one would easily ascertain

> the optimal delay, because I think it would depend on which meddling

> app is interfering with the build.

Exactly the problem... which is why I'm asking what the delay is with your particular meddling app. If we establish a set of data points, that would help us decide whether/if there's a good threshold to add.

> A "one size fits all"  delay doesn't seem like a good long term approach.

True, but few people ever change Tools >> Options settings, so it's important to establish the default for an option at an optimal point.

[Mr._Jim]

> which is why I'm asking what the delay is with your particular meddling app

This might sound like a cop out, but it's really difficult to determine:

The main reason for this is that the build takes several minutes, and when the "Build Errors" dialog appears, one has to restart the build, which takes another several minutes.  By the time the subsequent build attempt gets around to the end, which is where the resources are packed into a single file, it may have been at least thirty seconds for the simplest of builds.  (several minutes in this case)

Secondly, this specific error (error 😎 hasn't occurred for me again since this initial post.   Once I get back to my company laptop I'll see if I can reproduce it again.  I've certainly had plenty of these errors in the past that made successful builds a game of chance, but that was at my prior job with a different PC and antivirus.  If I start getting to the point where this is occurring frequently again, I will certainly break out Process Explorer and try to figure out what the optimal retry interval might be.  (Again, I know it sounds like a total cop out.  )

Maybe the retry idea isn't worth pursuing yet.  It seemed like a good idea at the time.  : )

In any case, thanks as always for your diligence in responding to all the comments.

[AristosQueue (NI)]

> Maybe the retry idea isn't worth pursuing yet.  It seemed like a good idea at the time.  : )

I think it is worth exploring... and you have put something of a bound on the problem. We aren't talking about a 50ms delay or somesuch... we're talking about 30 sec to a minute.

If we did keep retrying for a full minute, how bad a user experience is that, especially in the case when the file is legitimately locked and no amount of waiting is going to unlock it?

[tst]

The delay might be a red herring. I'm not sure, but it's possible that if I retry the build with the folder still open, then the build succeeds the second time around (I'm not sure because by now I usually remember to close the folder and if I don't, then I close it before retrying the build). Assuming it's true, it's basically the same thing Jim describes, but I'm not convinced it happens because of the delay.

I think the key is in understanding why the error actually exists. If I understand the build process correctly, LV generates a folder with all the built VIs in it, then basically zips that folder up and adds an executable stub to load everything up. The error seems to occur somewhere around the second part. If the folder is open, you can see the folder being created and the build runs through. Then, when it gets to the end, that's where the error is, so the error might be because the AB created the ZIP file and then tries to modify it when someone else is looking at it or it might be something else. Knowing what the correct answer is is probably the first step in solving the problem.

[matt.baker]

Same with this error:

Give me a path!