LabVIEW 4.0 Invalid Page Fault Errors

[Blair_Hogg]

I've got myself stumped on this problem - we had a LabVIEW based PC/DAQ system that started giving invalid page fault errors and crashing in Win95. This may have been concident with a revision to a vi file. To rectify the problem I've tried the following:

1. Reinstall LabVIEW 4.0 with NI-DAQ 6.6

2. Wipe HD, reinstall Win95, LV 40, NIDAQ 6.6

3. Full HD scan and MEMTEST86 memory test

4. Install on another PC

The PCs are P5-60 Gateways with 128 MB of RAM. DAQ config is 1 AT-AO-10 and 1 AT-MIO-16DE-10

Nothing seems to help. With a reinstall of LV40, I can get it to run, but once I copy the .vi files back into User.lib LV crashes.

Does LV40 look in User.lib upon startup and crash if it finds something it doesn't like? A corrupted vi?

Thanks!

[Blair_Hogg]

Update on this problem - it happens on multiple PCs, so I suspect a corrupted vi, but I tried to install a backup copy of the vi's from 2002 and get the same failure. This was working at one point on this station which is really puzzling. I even put LV40 on my XP based laptop (no DAQ devices), copied the files into user.lib and it crashed here as well.

I'm suspecting that I will have to put the vi's somewhere else, and the re-create all of the test executive sequences that pointed to vi's in user.lib. Apparently LV40 looks in user.lib when it starts as opposed to when you select the user library from the diagram toolbox, and is having a problem. I just don't understand why it worked in from 2002 to August and not in September.

And yes, I know I'm several versions behind in software.

[Blair_Hogg]

Well, on I hunch I deleted the dir.mnu files in user.lib and all of the folders therein. Now LV40 loads, but the user vi button on the toolbox has a question mark. I'm not concerned about this at this time. But I can't get any of the test executive sequence files to load. Still plugging away at it.

[Blair_Hogg]

Sorry that this seems to have turned into my personal blog on this issue...

In a somewhat blinding flash of the semi-obvious, I noted that all of the .vi, .seq an etc files were set with the read-only attribute. I had previously been backing up and restoring via Iomega Zips, but recently started CDs (Zips from the PC, CDs to restore), since burners are fairly common lately. Apparently when brning or restoring the R attribute is set.

I still had to remove the .mnu files, but now I can load the .seq files in test executive. Almost. LabVIEW crashes in the middle of the file load during the opening of the sequence file in test executive.

I guess the next step is to go in and load each .vi manually to see if there is one that is causing problems.

Hopefully some of you out there are finding this somewhat interesting, and I'm not just cluttering up the forum.

[Philip_Courtois]

---

@Blair Hogg wrote:

...guess the next step is to go in and load each .vi manually to see if there is one that is causing problems.

Hopefully some of you out there are finding this somewhat interesting, and I'm not just cluttering up the forum...

---

Hi Blair Hogg,

I like your sence of humor 😉 Don't worry, even if nobody reads your thread (well... I just did) you need to write MUCH more for it to be considered clutter. Now, if you had created 25 duplicates of the same thread, then  we would be talking about cluttering...

I'm curious about this issue even thought NI only supports LabVIEW two versions back - officially. My guess is that a VI is corrupted and kills LabVIEW when the VI loads. Therefore I do aggree that the procedure from now on is to load every single VI one by one and then notice what VI will make LabVIEW crash. I might be able to repair that VI if you submit it to the thread.

Another thing to try is to mass compile the user.lib. The log after the mass compile will show if any VIs were bad or had problems getting compiled.

Well, I hope you find the source for this issue - even if I'm the only one that cares 😉

Have Fun!

[Blair_Hogg]

Philip,

Thanks for your suggestion. I've done the mass compile, it works here but not on the actual PC where LabVIEW will be deployed. It is helping me determine where the problem is and hopefully by tomorrow I'll have it corrected.

Blair