Picture graph problem LV8.5 crashes

[AKJohn1]

I have an error that is giving me lots of trouble when running more than one XY picture graphs on computers running the INTEL Core 2/QUAD processor and INTEL DP35DP mother boards. The error I get at the time of the Labview crash is, Labview.exe ModVer 8.5.1.1, AppVer 8.5.0.4002, ModName LvAlarms.dll Offset 00010b44.

The same software runs fine on other computers using slower processors and different mother boards. I have done a clean install and not loaded any other software other that WinXP Sp2 and Labview 8.5. I have also tried and did disable any unneeded functions on the INTEL DP35DP mother board that were not essential with the same results. I have tried this on two different machines using the same mother board processor configuration an LV will crash on both with multiple picture graphs running. The Quad core processor speed is 2.4GHZ and system memory is 2GB DDR2-800 PC6400.

Can anyone shed some light on what could be causing such a problem with the processor and board combination? Or is this problm not related to such a combination and caused by a so far unkown cause. I have not discovered anything wrong with my code.

[eek]

Hi,

After LabVIEW crashes, upon reopening LabVIEW, is there an window with options on whether to investigate the errors that caused the crash? If so, you should choose to investigate the error. This will automatically send a copy of the error log file to National Instruments whereupon an Applications Engineer can directly work with you to find the causes. Moreover, if the behavior can be reproduced on our end, we can work to find you a fix or a possible workaround and also look to eliminate the behavior in future releases of LabVIEW.
I believe looking at the error log file will provide more details that may help us solve your issue.

Cheers,
Emilie K | National Instruments

[AKJohn1]

I have been trying to print the error dump file but it gets deleted automatically and will not allow shared viewing.  I will try a file recovery to see if it is possible to work around this problem. I do not have internet connection to the effected machines. A quick scan of the error dump file showed this:

 R:\jupitar\rtsource\timedloopschedular\lvinterface out of memory!

Is this why the system reports that it cannot write to a referanced memory location and then LV dies? What allocates this memory?

[AKJohn1]

I have replaced all the timed loops I was using on the host computer with while loops to work around the issue I described in my posts. The loop rate time is unchanged at 100ms. The changed from timed loops to while loops fixed my problem on the two machines running the INTEL motherboard board and Core 2 Quad processors. The code prior to converting to use while loops was tested on two laptops and three work stations and showed no problems on these. Those machines only used single processors and ran at lower speeds. Since the conversion was done to while loops the code runs as expected and does not kill Labview every 30 seconds to five minutes depending on how may timed loops were running to handle graph data..

I noticed, and I'm still somewhat confused as to why the heading of the error display prior to converting to while loops mentions an AMD CPU feature code when the CPU is a INTEL Core 2 Quad. Is there something in the Labview timed loop code that is set to use an AMD only feature code? I have been unable to salvage the error .dmp file that is automatically deleted.