LabVIEW 2010 unstable on Windows 7

[dbaechtel]

Your story sounds so much like my experience.

[Jon_S.]

---

@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!

[RavensFan]

I can confirm this behavior with LV2010f2 on Win XP SP3.  Right clicking sbus's control that is opened up in the control editor causes LabVIEW to just disappear.  Reopening LabVIEW gives no indication that an error occurred or any chance of a recovery.

[Christina_R]

I have reproduced this crash with the typedef in LabVIEW 2010 (and also in LabVIEW 2009) and it should be fixed in a future release.

The workaround is to make the listbox a control rather than an indicator. Since you can't right-click on the listbox in the Control Editor, you would need to copy it to a VI, change it to a control, and then copy the control into the type definition.

[dbaechtel]

I do not hva any listboxes in my tepe def. This could not be a fix for the problems that I reported.

[Christina_R]

The workaround that I described was for the problem reported by Gary Sloane, which is a crash when building the right-click menu of a listbox indicator in a custom control or global.

[SimonH]

dbaechtel,

LabVIEW won't send us any crash/debugging information unless it explicitly asks you so it's unlikely we have anything to go by (as an aside, this is a process we know we need to work on improving).  

Would it be possible for you to send us the code that is causing LabVIEW to disappear?

I've noticed you've also reported some other problems with editor instability/non-responsiveness.  Even if you can't send us code that isolates a specific, repeatable problem, it might be beneficial for us to look at your larger application if you are able to send us that too.  At the very least we could use your application in our test suite to validate future fixes.

Feel free to email me if you prefer not to post your code publicly (simon.hogg@ni.com).

Regards,

Simon Hogg

LabVIEW Product Manager

[dbaechtel]

I can not send you any code. It is all restricted by an NDA agreement beyween me and my customer.

If you need information on the cause of the crashes and other anomolies, you are going to that to instrument the LV code to save the information that you need so that I can send it to you.

[sbus]

Ok, some news.

MOST of my Win7/64-bit stability issues with Labview have gone away. I actually haven't had a real crash for almost (yeah!!!) 6 days.

What did it?

Well... it wasn't Labview. It was... ZoneAlarm. I updated to ZoneAlarm Internet Security Suite version 9.3.037.000, and VOILA!!! no more crashes/blue screens. The release notes from ZoneLabs state that the update includes "Win7/64-bit stability fixes" but does NOT specify what they might be.

I solve my problem related to dropping my typedef  .ctl on the front panel causing a crash - the control contained an X-control. Briefly: X-controls are incorrectly and incompletely docuemented; and the implementation of X-controls is done in a less-than-optimal (that means: stupid) way. X-controls try to keep track of the version of the control. One of the methods used is an internal timestamp. When the timestamp is changed the control thinks it's a new version. I modified the display state in the Init method of the control, which caused the framework to update the timestamp. Since the Init method is called by the framework, it got in an infinite loop and crashed. I simply changed it so that instead of using Init, I created an Initialize property, whcih *I* call, instead of the framework. Fixed it.

I'd be VERY interested to see if those of you with lots of crashes are running ZoneAlarm; and if updating it caused your problems to diminish also...

Gary

[dbaechtel]

---

@sbus wrote:

Ok, some news.

MOST of my Win7/64-bit stability issues with Labview have gone away. I actually haven't had a real crash for almost (yeah!!!) 6 days.

What did it?

Well... it wasn't Labview. It was... ZoneAlarm. I updated to ZoneAlarm Internet Security Suite version 9.3.037.000, and VOILA!!! no more crashes/blue screens. The release notes from ZoneLabs state that the update includes "Win7/64-bit stability fixes" but does NOT specify what they might be.

I solve my problem related to dropping my typedef  .ctl on the front panel causing a crash - the control contained an X-control. Briefly: X-controls are incorrectly and incompletely docuemented; and the implementation of X-controls is done in a less-than-optimal (that means: stupid) way. X-controls try to keep track of the version of the control. One of the methods used is an internal timestamp. When the timestamp is changed the control thinks it's a new version. I modified the display state in the Init method of the control, which caused the framework to update the timestamp. Since the Init method is called by the framework, it got in an infinite loop and crashed. I simply changed it so that instead of using Init, I created an Initialize property, whcih *I* call, instead of the framework. Fixed it.

I'd be VERY interested to see if those of you with lots of crashes are running ZoneAlarm; and if updating it caused your problems to diminish also...

Gary

---

I am not running zone alarm. I am running MSE.