Application Builder error in LabVIEW 7.0

[Bob_Schor]

I am maintaining some legacy code in LabVIEW 7.0.  I have recently (perhaps within the last month or so) been getting Error 1003 in Dist Copy Non-VI Files.vi (part of App Builder) when building my code.  I've done some testing, including trying to build much simpler VIs, and get the same error.  Curiously, this occurs on multiple (Windows XP SP3) machines, both "real" and "virtual", including on two of three installations on a single PC (so it is not hardware-dependent).

I have a strong suspicion that the problem is neither my code nor LabVIEW itself, based on the following logic:  1) This problem arose on multiple PCs at about the same time (i.e. I don't recall seeing this a few months ago, now I see it on almost all of my PCs).  2) There are two PCs where I do not see this error -- when I check the LabVIEW installation files between a PC that "works" and one that doesn't, the differences seem (to me) to be small, more related to "what did I do most recently" or "how much of MAX did I install, which drivers".  (3) Using or not using OpenG in my code mades no difference, nor does turning off Anti-Virus scans.

I tried two other things.  First, I have a VM that I recently build (which I think is significant) that has both LabVIEW 7.0 and LabVIEW 7.1.  The build fails with LabVIEW 7.0, but succeeds with LabVIEW 7.1.  In addition, I found a VM, built a year ago and "sitting idle", with LabVIEW 7.0 on it.  I fired it up, did not allow Microsoft Update to update anything, and tried the build with LabVIEW 7.0 -- it worked!

My current working hypothesis is that some "patch" installed by Microsoft (.NET? ActiveX?) has clobbered something in the LabVIEW 7.0 Build Application.  Unfortunately, the VIs that make up this application are password-protected, so I can't see "inside" to discover what file or other condition is responsible for the error message.

Does anyone have any ideas or suggestions?  [Don't suggest "Upgrade to 7.1" -- I'm the only "maintainer" of multiple PCs and multiple applications, some of which run on systems "belonging" to other people.  I am in the process of rewriting the code in "modern LabVIEW" (2011) and will port it widely, but until then, it's not practical (or "politically correct") to make the 7.0 -> 7.1 shift ...  Besides, my curiousity is piqued!]

Bob Schor

[smercurio_fc]

Do you have an example of code that doesn't build? I have LabVIEW 7 on my Windows 7 machine via Windows Virtual PC, so I could test it out for you.

[Bob_Schor]

Make a While loop and wire a Stop button to the Stop terminal.  This almost-trivial VI will fail to build, giving a 1003 error.  The point is that any (or may I should say all) VIs fail to build, whereas the same PC and LabVIEW 7.0 installation, a few months ago, had no problem building an executable with hundreds of VIs.  My "guess" is that a Microsoft "patch" has rendered Windows XP SP3 + LabVIEW 7.0 faulty, The trouble is to figure out either (a) what changed to "break" the App Builder and to "undo" it, or (b) figure out what is now not working, and changing/repairing the App Builder so that it continues to work with these systems.  I should note that I've been trying this on multiple systems, and the only ones that seem to "build" correctly are ones that have been turned off for several months, hence have not been recently updated.

BS

[Bob_Schor]

If you are going to test a build in a VM, make a clone of the VM first.  If the build succeeds, try going to Microsoft Updates, applying all the available updates, and try the build again -- it will be extremely revealing if you go from success to failure!

BS

[tst]

I have an XP SP3 VM, where I just applied all the important Windows updates (somewhere on the order of 120, as it's been a while), including the relevant .NET updates (I believe it has 2.0 installed, although the updates also said something about 3.5, so that might be there as well) and after restarting the VM, LV 7.0 still builds apps correctly, including one which has all kinds of ActiveX and .NET calls.

So, if it is a matter of Windows update, it would seem to be a specific update which I don't have.

[Bob_Schor]

Wonderful!  I'm going to try the same thing myself -- I have one PC that is a "quadruple-boot" PC (three copies of Win XP and one of Win 7) in which two of the XP machines "work" and the third doesn't, and also a VM with XP that "works" (along with multiple VMs that don't).  I'll also try "selective updates" and tests, trying to see "where they break".  [I should also see if I can get Windows to tell me which updates have been applied, and then compare "systems that work" with "systems that fail" ...].

Meanwhile, I believe the Intrepid Engineers at NI are trying to find out more about the Error Message itself (like give me a clue what operation or what file is precipitating the error -- this, in itself, may suggest a solution, or, perish forbid, reveal a subtle "bug" in the Builder code ...).

BS

[smercurio_fc]

I also was able to build just fine. You seem to have your laser beams focused on OS updates. While it could be one them, it's also possible (and in my opinion more likely) that your LabVIEW install is corrupted. Have you tried to do a repair? I'm not sure if the installer at that time allowed repairs.

[Kennon_Cotton]

Bob,

'Dist Copy Non-VI Files.vi' like the name implies copies files that are part of the build that aren't VIs (DLLs, data files, mnus, etc).  For what ever reason it calls <vi.lib>\Utility\libraryn.llb\Librarian Copy.vi dynamically and that VI or one of its subVIs must be broken for some reason.  I think enough of it and its subVIs are not password protected so you should be able to figure out why it is broken and fix it.  I don't see anything in the hierarchy that I think would break with a Windows update, but I'm looking at the 2011 copy of the VI.

Kennon

[Bob_Schor]

Good point.  The reason for my "laser beams" is several fold.  First, I follow a written protocol (I wrote it!) whenever I install or re-install LabVIEW 7.0, so I'm pretty sure that all of the installations "should be consistent" (if not identical).  Second, I compared two NI folders in Program Files between a version that worked and one that didn't, and while there were differences, it seemed "not likely" to be an explanation.  Third, I'm 99% sure that at least one of the systems that now cannot build (of the eight installs, all by me, that I've checked, only three worked, and one was on a PC that hadn't been turned on in over a year, hence was certainly not updated) was able to build previously (i.e. I don't recall seeing this problem until about a week ago, when I started re-building an update to my legacy application).  It is possible that this problem was always present on these systems, but doesn't seem likely.

Nevertheless, before the beginning of next week, I plan to take one of my "failing" systems, uninstall LabVIEW (but not change the OS in any way), reinstall it, and see if I can build.  If this still fails, I'll take the "old" system I mentioned above and start bringing it "up to speed" until I "break" the App Builder.  Note that it is possible that MicroSoft is not to blame -- I have other software (such as editors, utilities like WinZip, etc.) that have also been updated, and one of them might have clobbered the Builder.

Will let you all know what I find.

Bob Schor

[Bob_Schor]

I'll poke around a bit.  The Dist Copy Non-VI Files VI definitely is password-protected in Version 7 -- haven't looked at the others.  As I noted, I get this failure when trying to build a VI consisting of only a While Loop and a Stop button, so what "Non-VI" files are there to worry about?  Incidently, I've now checked the other VI's in the call chain to this error, and they are also password-protected in LabVIEW 7.0.

BS