Showing results for 
Search instead for 
Did you mean: 

LabVIEW crashes in timed loops


I'm running LabVIEW 8 on a Pentium D, 2 GB RAM, Windows XP sp2 with an ETS target Pentium 4, 256 MB RAM. I have two timed loops in a sequence, so they do not execute at the same time. A similar sequence is on the target allowing me to make a state machine between both computers.

The loops on the host simply update the GUI for the user have a large period of 45-ms. This makes the CPU usage virtually zero. Also, task manager tells me that LabVIEW on the host only uses 200 MB of memory, so I know that the computer is not running out of memory.

When I run the multiple VIs, the host will randomly crash. It works about 9 times out of 10 with no crashes. Windows will tell me that it (is sorry and) has to close LabVIEW on the host. The target side continues to run like nothing happened. When I click on the link requesting details, I get this information from Dr. Watson:

AppName: labview.exe
ModName: lvalarms.dll
Offset: 00001df4

I have narrowed it down and I know that it will only crash in the two GUI loops. Does anyone have any ideas about how to approach this problem?
0 Kudos
Message 1 of 12
Recently, I have had similar problems with timed loops (LV8.0.1/W XP). According to NI's answer, this is linked to hyperthreading. Unfortunately, until now, my question if this incompatibility is a bug or not remains unanswered. Because my application is critical, I have replaced all the timed loops with while loops even if the crash didn't appear during a short test with disabled hyperthreading.
Hope this solves your problem.
Here is an extract of the exchange with JR Andrews from NI :
The preliminary investigation of the issue indicated that it may be due to hyperthreading (or having dual processors) and that disabling hyperthreading resolved the issue as a potential workaround. If you have the time and ability, I would be interested to know if you were seeing the issue on a hyperthreaded machine and if disabling hyperthreading does in fact resolve the issue for you. I can then pass that information on to the developer to assist them in fixing the issue.


JR Andrews | LabVIEW Real-Time & PDA Product Support Engineer | 512-683-2820
Even though your computers only have 1 processor, that processor may be using "Hyperthreading" to make it appear to the OS that there are 2 processors. You can check this by looking that Performance tab in the Windows Task manager or at the number of processors shown in the Device Manager. I've attached a screen shot of my system which is a single P4 processor which is hyperthreaded. Disabling the LV option for "Run with Multiple Thread" would probably not have any effect because to Timed Loops are always their own thread and that setting only applies to non-timed loop LabVIEW code. So I wanted to clarify that double check that your machine indeed does not have hyperthreading. To disable hyperthreading, you can go into the BIOS and you should be able to disable it. You can always go back and enable it again too.
Message 2 of 12

Thanks for the insight. Knowing this actually may solve more problems that we've been having other than just timed loops. That's interesting that the lvalarms has such problems with hyperthreading or dual core machines. We have a dual core machine here that does not have hyperthreading (didn't want to spend the enormous amount of money for the little performance boost) and had the crashes. I've switched to the while loops and there is no problem now that I've noticed. Hopefully NI releases more information about this or provides a fix for the dual core or HT machines. A warning list about the problems associated with interactions between dual core/HT machines and LabVIEW would be nice.


0 Kudos
Message 3 of 12
I will post it here if I hear something new about this.

Have a nice day.
0 Kudos
Message 4 of 12

Hi everyone

I have about the same problem described with the timed loops, as discussed above disabling hyperthreading stops the application from crashing.

My problem is that if I disable hyperthreading my application consisting of six timed loops doesn't execute the lower priority loops anymore. Is there a solution to this bug at that point?

Has anyone tried a dual processor with disabled hyperthreading? Is this a possible workaround?

Thanks in advance!


0 Kudos
Message 5 of 12
Hi RalphRA,

What version of LabVIEW are you using? If you can attach an isolated version of the code, which is able to reproduce the crash, that would be great. It will help us investigate the issue and, if needed, will help us in filing a CAR. Have a great day!
Adnan Zafar
Certified LabVIEW Architect
Coleman Technologies
0 Kudos
Message 6 of 12
Hi AdnanZ
thanks for your reply!
I'm using the latest version, as far as I'm aware, 8.20. Reproducing the error is quite complicated because on my setup it takes about 10hrs and I haven't been able to get it to crash on another computer. I'm deploying the program as an exe, I'll check if running the whole thing on the simulated DAQ as an exe gets me anywhere, could take some time though.. I'll let you know about that one and post or preferably mail you the program.
Raphael Wittwer
Deveopment Engineer Testing
RA Aarau
0 Kudos
Message 7 of 12
Hi everyone
over the weekend I tested my application with disabled hyperthreading on my target pc and, oh wonder, it works fine. Of course it's too slow to really work with it like that but at least there was no crash.
Does anyone have any experience with this issue on dual processor machines? I have to get this project running asap and am willing to buy myself out of this bug, but at least I have to know wheter there is any chance with dual core or dual processors.. The other possibility of course would be using three PC's instead of one, altough ugly this is my preffered "solution" at this time.
thanks a lot!
0 Kudos
Message 8 of 12
as Jason wrote about Problems with dual core computers I will go for the three computers approach. At this time this seems to be the only workaround, I will test that somewhen in the following weeks..
0 Kudos
Message 9 of 12

eliminated all the timed loops, replaced them with normal while-loops, seems to work fine now. screw the timing! ;-)


0 Kudos
Message 10 of 12