LabVIEW sure loves to crash for stupid reasons.

[Intaris]

We had crazy amounts of crashes until recently.

We installed the f3 patch for LabVIEW 2015 SP1 and that seemed to fix a lot (we use a lot of DVRs and Events).  Additioanlly, we found out that we had some corrupted controls on our FPs which were causing some weird UI slowdown (cumulative over time) and replacing these also means I now have the occasional week without a crash!  That was unthinkable before where we had typically a few crashes a day.

[QFang]

Intaris, could you elaborate how you tracked down which controls were corrupt?  It has been a long time since last something similar happened to me, but for me, it ended up being 'strange behavior that is absolutely incorrect' and in my last ditch attempt before throwing the PC out the window, I deleted and recreated some functions and constants/controls.. suddenly, the code worked..  I've always been a little bit more afraid of the dark after that happened...

At any rate, if you found a way to (by script or server) check/find such problem objects, that would be amazeballs if you could share it.

[Intaris]

I'll try to get something organised, it involved a lot of non-LabVIEW investigation.

Just using the word "Amazeballs" makes me want to write something on the subject.

[billko]

---

@Blokk wrote:

---

@BowenM wrote:

The most common crash I see is an access violation when attempting an undo operation (ctrl-z).  In small projects it never seems to happen, but once a project grows above a few hundred vis or so it seems to happen much more frequently.

---

Hmm, the size of the project can be an important factor then? This would explain why I do not see crashes: i never develop large apps, usually the number of VIs stays below 100-200... Also due to my OCD, i only keep open max 3-4 VIs at the same time 🙂 So for sure, i am not a good reference here i have to admit...

---

I've only ever had LV exit with warning with multiple undo-redo's when exiting LV.  I have had it crash for other reasons, not known, in the middle of doing things, though it happens maybe a few times a year?  Fortunately the recovery stuff was all I needed to get back on track.  Still, it's a few times a year too many, if you ask me.  I'm guessing it's rather more delicate than, say, Visual Studio, because - depending on certain settings - the VI you are working on, if not all the VIs related to it, are constantly being recompiled as you edit.  That's why you get the broken arrow right away if something is wrong with the VI.

And LV is deadly to my OCD.  I can sit there for hours getting everything "just right" if I let mysef do that.

[Intaris]

I've since posted a bit on our recent debugging journey.  I even managed to fit the word "amazeballs" in there....

http://forums.ni.com/t5/LabVIEW/Debugging-exotic-LabVIEW-problems-Performance-Monitor/m-p/3350169#U3...

[ben64]

For me the LV version that crashed the most was LabVIEW 8.x. After that I didn't encounter much crash and I realized that when these crash happended they were often caused by VIs that I developped using LV8 and were recompiled by a more recent version. I recreated theses VIs from scratch and since then the number of crashes are close to none (I can't remember the last time it happens).

Ben64

[BillMe]

Windows 7 64 bit, LV 2015f1 32 bit (I use N.I. FPGA), no AV but if/when it gets installed, the automatic scan will be turned off as it interferes with the performance of the executable.

[BillMe]

A few times a week is still unacceptable in my book.

[BillMe]

I will check with my admin to see if f3 is available to me.

[BillMe]

Yes, I have a fairly large Actor Framework project.with about 3500 files.