From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2018 crashes a lot!

Anyone else having crash issues with LV 2018?  I have been using LV since 2005 and I have never had LV crash problems like this.

 

We run 32-bit LV.  Crashes at times seem related to the use of a particular VI (such as the File Dialog express vi), and other times just systematic crash death.  It will work in the design environment and crash in a compiled EXE at some times, and crash in the design environment at other times.  We have tried uninstalling and re-installing LV and this has not worked.  Multiple users on multiple machines experience problems.  We have tried re-building from scratch vi's that seem to crash and this doesn't always fix the problems.  Any thoughts?  Any 2018 updates?  If I could go back to 2017 I would.

Message 1 of 23
(4,104 Views)

2018 is pretty stable.  Which makes me wonder how stable your code base is.  Did you follow the upgrade instructions?  What unit test changes occurred during upgrade?  Were any warnings thrown by the mass compile process?

 

Or, did you just install a new version delete the old IDE and wing it?


"Should be" isn't "Is" -Jay
Message 2 of 23
(4,070 Views)

We have always been pretty careful during a LabVIEW upgrade process.  Like I said, I have been doing this since LV 7 without experiencing the type of instability I experience with 2018.  The "wing it" comment was funny.  A little cynical and uncalled for, but funny.

0 Kudos
Message 3 of 23
(4,063 Views)

I am a little cynical... did the mass compile step generate any warnings or errors? I don't have your codebase to mass compile myself.

 

Just trying to help you understand what may be causing your crashes...do you have error reporting turned on? NIER Services ...


"Should be" isn't "Is" -Jay
0 Kudos
Message 4 of 23
(4,061 Views)

There were some issues, and we addressed all of them.  Again, a step we always carefully go through during LV upgrades.  We have been fighting with this for a while.  I did a re-install of LV at one point and seemed to fix things, but I think it was only temporary.  I am suspicious of corrupt LV components?  I built an EXE and installer for this app yesterday, made some changes today, built the EXE and installer again and now it crashes when loading a particular front panel plug-in.  Funny thing is that I did not even touch the code for the now crashing vi.  LV is rotting.

0 Kudos
Message 5 of 23
(4,057 Views)

Do you separate your compiled code from source? We have pretty much marked all of our code that way and don't experience issues with upgrades. We still mass compile everything when we upgrade. Also, are you using any packed project libraries? We found that they need to be rebuilt when any code changes occur. We have PPLs using other PPLs. We rebuild all PPLs any time we change any of our PPLs.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 6 of 23
(4,053 Views)

Just throwing it out to eliminate it.   You cleared the obj cache? 


"Should be" isn't "Is" -Jay
0 Kudos
Message 7 of 23
(4,032 Views)

Yes, didn’t help.  I am uninstalling all packages installed through the package manager to see if there is a corrupt package issue. 

0 Kudos
Message 8 of 23
(4,025 Views)

Is there a way to decouple the source from the compiled code? How ddi I set that up to test?

0 Kudos
Message 9 of 23
(4,026 Views)

I usually wait for the SP1 patch before moving everything to a new LabVIEW version.

 

Still running LabVIEW 2017 SP1

========================
=== Engineer Ambiguously ===
========================
Message 10 of 23
(4,017 Views)