LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW 2024 Q3 Crashing with Custom Menus

Solved!
Go to solution

Hello,

 

I have a large application which was working fine in LabVIEW 2024 Q1, however, I foolishy updated to 2024 Q3, and have discovered there is a bug which I cannot trace down with custom drop-down menus.

 

I add custom entires in the VI's window's menus, they had all been working fine, however upon updating, whenever I select one of my custom drop down menu selections, LabVIEW entirely crashes with no warnings or explainations.

 

Gryffin_0-1722611124904.png

 

This is the .dmp file associated with the crash, which provides this explaination: "The thread tried to read from or write to a virtual address for which it does not have the appropriate access"

 

Does anyone have insight?

 

I am about to be forced to rollback to 2024 Q1 because of this bug.

 

Message 1 of 32
(1,344 Views)

I moved my project over to another computer with LabVIEW 2024 Q1 and tested, LabVIEW 2024 Q1 DOES NOT CRASH.

 

I can create simple menu additions in basic VIs in 2024 Q3, but in a large actor-framework program with multiple menus being handled, something seems to have broken in the new version.

 

 

If you have menus in your programs, DO NOT UPDATE TO 2024 Q3.

Message 2 of 32
(1,330 Views)

There isn't really enough information in the post to provide any meaningful insight. You'll probably have to generate a full dump and work with NI TSE to figure out what's actually happening.

 

The access violation 0xC0000005 is pretty generic. One of the reasons it could happen is trying to read or write to a null pointer, but this by itself doesn't help us understand what went wrong and how to fix it. If the access violation is from a Windows function call then all we really learned is that selecting a menu item kicks off some call chain within LabVIEW runtime, something goes wrong that eventually leads to the LabVIEW runtime passing a null pointer into a Windows function.

 

I believe the module list below that just lists, in order, every DLL that eventually gets loaded by LabVIEW. It's not usually helpful, though sometimes scrolling to the bottom and seeing what LabVIEW loaded last can help if you don't even know where LabVIEW is crashing.

 

Really you would need to look at the call stack but if you don't have the LabVIEW PDBs you would only see the DLL name for any internal LabVIEW functions.

0 Kudos
Message 3 of 32
(1,318 Views)

I can confirm this issue in Windows, 32-bit version. It appears to only happen when running in development; built EXE version is fine. Thanks for the warning, I didn't think to check this (just like NI)!

 

An extra note: it isn't caused by dynamically registering for menu events, I disabled that just to check.

Message 4 of 32
(1,305 Views)

So, 2024 Q3 is broken and I've been forced to rollback to 2024 Q1......


Previously I've found an unrelated bug in an earlier release of LabVIEW (https://forums.ni.com/t5/LabVIEW/Rescripting-Actor-Messages-in-LabVIEW-2023-Q3/td-p/4321748) which forced me to rollback and they didn't fix it until next quarter, despite it crippling the Actor Framework Rescript feature.

 

Is there any acknowledgement from NI regarding this issue, rendering the latest version of LabVIEW unusable?

0 Kudos
Message 5 of 32
(1,213 Views)

@Gryffin wrote:

 

Is there any acknowledgement from NI regarding this issue, rendering the latest version of LabVIEW unusable?


You'll have to engage with NI technical support to get a bug report created and find a potential workaround.

Message 6 of 32
(1,198 Views)

Hey avogadro5, how did you reproduce this bug? NI Technical Support is being very unhelpful

0 Kudos
Message 7 of 32
(1,149 Views)

@Gryffin wrote:

Hey avogadro5, how did you reproduce this bug? NI Technical Support is being very unhelpful


Absolutely shocking to hear 😉. My company has a proprietary "actor framework" that I definitely can't post here that is quite similar to the NI one, with a lot of parallel ACBR VI "actors". Many of the actors opt in to have their menu bar replaced with a common one which will run this on a reference to the "actor core.vi" equivalent.

 

avogadro5_0-1723140165561.png


In 2024 Q3 development, if you select a menu item after this, LabVIEW crashes. I didn't try testing it without the rest of my framework and I can't replicate again at the moment as my trial expired and it takes a while for new LabVIEWs to make it into our license server.

 

Edit: We set the cursor to busy because previously we found that if the user tries to interact with the menu while this swap is going on, LabVIEW would crash. Could be related?

0 Kudos
Message 8 of 32
(1,139 Views)

I attach here the simplest possible form of this bug to demonstrate behavior to NI technical support.

 

It is just a single actor in an otherwise blank project:

Gryffin_1-1723153693346.png

This is the "Actor Core.vi" override which simply can stop and add a menu item by pressing a button (VI attached):

Gryffin_2-1723153760875.png

Gryffin_3-1723153777502.png

When one presses the "Add menu item button" and then clicks on the new menu item, like so:

 

Gryffin_4-1723153959577.png

LabVIEW 2024 Q3 will silently crash and produce the .dmp file that I first posted.

 

I have checked on several machines, this bug has crippled LabVIEW 2024 Q3!

Message 9 of 32
(1,107 Views)

here is the second clean example with no dependencies and error checking.

Message 10 of 32
(1,073 Views)