LabVIEW 2010 unstable on Windows 7

[dbaechtel]

I am finding that LabVIEW 2010 is fairly unstable on Windows 7 Ultimate system.

LV stopped working several times, LV tells me that it stopped working, looks for a solution and then shuts down. Like just a few minutes ago, shortly after system power up.

Several times it just closes all of the Windows and terminates without any message or error displayed.  Didn't even say goodbye.

I have even had one BSOD (which is hard to do on Win 7) almost immediately after an application was built and run. Didn't happen again when app was run again and built again.

I have only observed these problems with LV. All other applications have been running fine over the last month without unusual errors or misbehaver.

The system is only 1 month old. It is fairly clean with minimal software installed.

I don't know how much data on these problems that NI is capturing automatically. I haven't seen my system request permission to send problem reports to NI.

Has anyone else seen similar behavior with LV and Win 7 Ultimate?

[dbaechtel]

I am getting more consistent results on the LV Stop running issue.

Visual Studio is reporting that it is an unhandled exception within LV that is the cause. Without LV symbols to load I do not get more information about where in LV it is occurring.

What I have been doing to cause the problem is I am deleting an Event Case form and Event structure that is no longer needed. As soon as I request the Delete, BOOM ! Error message.

I will provide more information if I can.

Is there anyway that I can get LV symbols to load into VS so that I can get more details about what is executing at the time?

[Intaris]

You're not alone in wishing for more stability with LV in general.

Feel free to pop by and drop a vote on my idea for an LTS version of LabVIEW.

Shane.

[dbaechtel]

A little more information for the Event Viewer:

LabVIEW information: Error: 404 "Not Found" for "national instruments/ni-rpc/interface/eadfc80d-1e6f-425b-8986-12ccef98f646", file "c:/program files/national instruments/shared/ni webserver/www/national instruments/ni-rpc/interface/eadfc80d-1e6f-425b-8986-12ccef98f646": Can't access URL .

There is no directory c:/program files/national instruments/shared/ni webserver/www/national instruments on my system.

[dbaechtel]

I finally got that event case to delete. I had to delete the contents of the Event Case first.

I tried it 5 times and LV stopped working, produced a "LV stpped working" message and terminated each time.

When I deleted the contents of the Event Case, before deleting the Event Case, then it worked without error and did a Save All OK.

I am not sure what the problem was. The contents of the Event Case was OK and has been working OK unchanged for 2 days.

STRANGE.

[Intaris]

Make sure to fill out a bug report so that NI can fix the problem for future versions.

Shane.

[nferry]

At runtime, i have observed that some VI can block LV during executing.

This is the case when performing long loop with I/O on large file.

In this case, i must kill LV process to close the running program.

Is it possible to insert a global STOP button in the project explorer,

and exec LV program in a different process ??

This will permit to kill the runtime application without shutdown the entire LV.

Best regards.

Nicolas

[EvenDeejay]

I got Labview 2009 and 2010. I had this problems with LV2009, so I gave it full admin rights and I ran it as XP SP3. Problem gone. Have not been using LV2010 so much yet, but safety I run it as XP SP3. It's too bad it happened because now I pressing CTRL+S ever 10 seconds and people at work think I'm paranoid. It's getting better now so my CTRL+S interval is only 1 min.

[Norbert_B]

I am working with LV 2010 on Windows 7 and have not encountered anything which shows me that LV 2010 is more unstable than any other LV version on other Windows systems (so even on XP). But i have to admit that i am running LV under full admin rights.

Reading the messages you posted here it, it seems to me, that those crashes occur when working on code you (or someone else you know) implemented. So can you boil down the code to an example that we can use to reproduce the crash? Are there any non-LV components (e.g. DLLs, .NET Frameworks, ...) involved?

How does the crash occur? Are there any special interactions you have done before the crash occurred?

thanks,

Norbert

[sbus]

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.