LabVIEW 2010 unstable on Windows 7

[Jon_S.]

---

@Jon S. wrote:

---

@sbus wrote:

I too am extremely (that's a total understatement) displeased with the behavior of Labview 2010 under Windows 7.

I get frequent crashes, some with recovery/log/.error message, some where Labview just exits. One minute I'm editing my code with 7 windows up; the next I'm staring at an empty desktop.

I too have started saving my work every few seconds. It's a royal pain in the ass.

I have turned in NUMEROUS bug reports, including samples of code that cause Labview to crash. MANY of them are related to typedefs. I just found another one and will be turning in that bug report within minutes. In this case I have a typedef (NOT strict) that contains only a combo listbox. If I right-click on the combo listbox, Labview silently exits and does no recovery or logging when started back up.

I have lost SOOOOOO much time trying to create code while fighting numerous Labview 2010 issues. The most egregious (to me) is that I have a control (I *want* it to be a strict typdef) that when I drop it on the Labview block diagram, Labview crashes. Yes this has been reported. I had to change the control from 'strict typedef' to 'control' to use it. The result is that every time I have to modify it (it's a work in progress) I heve to go thru my code and change over 60 occurrences of that control. By hand. If it was a typedef, I would change it ONCE.

I have a customer I'm developing Labview code for; I find it both personally and professionally embarassing to be missing deadlines for delivery, and blaming Labview instead of myself. But I have 3 pages of bug reports online with NI; each one cost me between an hour and 3-4 days of time. Many of them required me to redesign code I'd alrady written to avoid using constructs in Labview that simply don't work.

I'm glad to know I'm not alone - but absolutely dismayed that the code base for Labview 2010 is so buggy under Windows 7; it may be buggy on every platform, but that's all I'm using.

NI tech support has been helpful; but only to a point. They routinely generate correction requests based on my bug reports; not one has resulted in a patch from engineering to date.

I've been a software engineer for over 35 years. This is probably the 2nd worst experience with an IDE that I've had. The first was with a Sun product that was supposed to generate user interfaces; it simply was crap. Labview is dismayingly similar. If I'd elected to write this application in C I'd not only be finished, but it would have taken 6 months less on the calendar. Some of that is due simply to the way you have to construct and enter code in Labview; but in my case, most is due to failures of Labview to work as documentd, or to failures in the Labview documentation to explain what Labview is really doing (yes, I've turned those in too).

Here's an example of a Labview crash: open this VI and right-click on the listbox on the front panel. Make sure you do NOT have any other Labview code open at the time...!

Gary Sloane

SB/US Engineering Inc.

---

This bug has been reported to R&D for further investigation (CAR 254558).  Thanks for the feedback Gary.  LabVIEW stability is our number one focus for the next few releases.  Being able to reproduce these issues really helps us locate and fix the particular bug.  Please continue to report these as you see them.  The more information we can get the better.

Thanks!

---

Hello Everyone,

I just wanted to let you know that CAR 254558 was fixed in LabVIEW 2010 SP1.  Thanks again to the individuals that helped us reproduce this bug and get it fixed.

[metzler]

I am using a new Dell Precision T3500 64 bit computer with quad core processor and 12 Gb ram, Win7 Professional, and running LV 32 bit so my VIs are compatible with 32 bit computers.

I only use the computer part time, because LV is not my 'hired for' job and they will not get someone to replace me, but I see LV 2010 SP1 lock up and shut down like you describe, probably once every other week.  These are the problem I am having:

1.  When I try to backup my VI to the network drive , if for some reason the computer cannot write to the drive, LV closes without any warning, shutting down project explorer and all VIs open.  I even had one time when it shut down for no reason, I recovered the VI, but the VI would not save because the 'file was corrupted' - what a nightmare.  I ended up loading a week old revision and updating that.

2.  It may be because my vi is stored on the network drive, but it seems to be  normal for a window that states I need to re-insert the drive, but then it runs okay.

3.  Frequently Windows reports that LV is not responding after I save the VI. This is because it takes so long to compile the VI before saving.  This may be my problem - I will make sure all my VIs are compiled with mass compile this week.

Is there a procedure to send NI the problem reports, or are they automatic?

[Roryriffic]

metzler,

Next time you try to save and see the "file is corrupted" dialog, try copying and pasting your entire block diagram to a brand new VI.  For whatever reason, this will occasionally fix corrupted VIs. 

Also, for more information on the LabVIEW compiler and how to optimize compile time, check out the two KBs below:

LabVIEW Compiler Memory Usage and Performance

How do I Change the Compiler Settings in LabVIEW 2010 SP1?

To send NI an error report, click the "Investigate Errors" link when you see the dialog box pop up after re-launching LV from a crash. You'll have the option to send the error report.

Are there any instructions you can give to duplicate the problem?

[metzler]

No, I do not know how to duplicate the problem.  I will have to start writing down what I was doing when it happens. 

I just installed SP1 on Saturday - according to the bug fix file, there are many instances that have caused lv crashes but have been fixed.  Hopefully, I won't see any crashes now.

[metzler]

I have not seen LabView crash since I updated to LV2010 SP1.  I have seen the computer lockup, which then corrupted MAX and prevented it from detecting my compact daq hardware. 

The first time this happened (about a month ago), I had to use the corrupted database for max utility.

The second time (just last week), the utility did not work, so I had to repair the max and daqmx files on the computer. 

This could be a very bad thing, as the products being testing may be 'stuck' in a state that could cause damage if it persists for a long period of time.

I  have considered using LV 64 bit but some of the toolkits (office report generation and pid fuzzy logic) that I am using are not available in 64 bit. 

Is there some way I can prevent max from corrupting?

[Aaron O]

Metzler,

MAX can become corrupted for different reasons, but it seems that your corruptions are happening because of computer freezes/crashes. Unfortunetly, this is can be caused by a very broad range of things, such as OS level crashes, hard drives issues, or LabVIEW related crashes.  If you can provide detailed information about the freezes, then we can work towards a solution for those freezes (which hopefully will in turn prevent MAX corruption).

Aaron 

[metzler]

I just had LV crash.  Before LV closed, a window reported "LabVIEW.exe - No Disk.  There is no disk in the drive. Please insert a disk into drive \Device\Harddisk\DR3."  This is the same error I sometimes get when I try to save the VI.

I have seen this before and just hit continue, and there was no problem.  This time, LV closed.  When restarted, there was no message about fault, just to recover the last file saved.   

My VI is located on the network drive - maybe this has something to do with it.

What could cause this error?

[metzler]

Restarted after the installation of win 7 service pack, and LV comes up with "Investigate Previous Internal Error", crash occured at fpsane.ccp, line 444.

[Brian_P]

Metzler,

The fpsane.cpp crash usually occur when a VI has been corrupted.  Check out this KnowledgeBase that addresses the issue and how to solve it.  Let me know if this helps.

Regards,

Brian P

[metzler]

This document is regarding the fpsane.cpp crash, but the real problem is LV closing without any notice. I could not find any insane objects that could cause this.

I really think the root cause is the "LabVIEW.exe - No Disk.  There is no disk in the drive. Please insert a disk into drive \Device\Harddisk\DR3"  error.  If I can prevent this, maybe LV would not crash.    

Thanks.