Application Builder error in LabVIEW 7.0

Question

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
Solved!
Go to Solution.

Answer 1

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