LabVIEW crashes without message after executing Actors

[Jenso]

Hey guys,

I am currently running into problems finding the root cause to a strange kind of crash where LabVIEW does not show me any crash message (it simply closes all windows) and after restarting LabVIEW it does not want to run again. In most of the cases a Windows restart does the trick.

Background:

I am currently developing a Plugin-based Actor-Framework Architecture which dynamically loads Packed Libraries and uses Interfaces for modularizing these. The error can be reproduced when I send a close message up to the root actor (comes from a second level child which is used as a view) that will then close the root actor with a normal stop.

The crash also happens in the built executable and it seems as if there is no Windows restart necessary as long as the Development IDE is not running.

CrashLog:

When looking at the crash log I see basically the following output (see file in the attachment for all data):

<DEBUG_OUTPUT>
22.02.2023 17:40:09.652
DWarn 0x46CB81E1: Unknown enum value in NumDependentClasses()
C:\dev\pg\labview\branches\2021sp1\dev\source\UDClass\OMUDClassLinker.cpp(5073) : DWarn 0x46CB81E1: Unknown enum value in NumDependentClasses()
[ExecSys:0; Executing:"[VI "AB_Build.lvclass:Open_Top_Level_VIs.vi" (0x00000247a1a24970)]"]minidump id: afecf4d6-0c90-480a-a644-a50f77c5ec17

</DEBUG_OUTPUT>

0x00007FF77467832B - ???W <unknown> + 0
0x00007FFBA1246702 - ??????? <unknown> + 0
0x00007FF77595A4B0 - ???W <unknown> + 0
0x00007FF77591B9C0 - ???W <unknown> + 0
0x00007FF7758F6930 - ???W <unknown> + 0
0x00007FFB9CABAD85 - ?????0 <unknown> + 0
0x00007FF774DAE371 - ???W <unknown> + 0
0x00007FF774DAF1D4 - ???W <unknown> + 0
0x00007FF774F0AECC - ???W <unknown> + 0
0x00007FF7753D424A - ???W <unknown> + 0
0x00007FF77525CDB6 - ???W <unknown> + 0
0x00007FF77525CD3C - ???W <unknown> + 0
0x00007FF7753DBDF8 - ???W <unknown> + 0
0x00007FF7753DAED3 - ???W <unknown> + 0
0x00007FF7753D9F9E - ???W <unknown> + 0
0x00007FF7753C8B44 - ???W <unknown> + 0
0x00007FF7753C7AEC - ???W <unknown> + 0
0x00007FF7753CC389 - ???W <unknown> + 0
0x00007FF7753CEE39 - ???W <unknown> + 0
0x00007FF7745EBF64 - ???W <unknown> + 0
0x00007FF7745EC691 - ???W <unknown> + 0
0x00007FF7745E9BE8 - ???W <unknown> + 0
0x00007FF7745E9B6A - ???W <unknown> + 0
0x00007FF774D2A860 - ???W <unknown> + 0
0x00007FF774D3493E - ???W <unknown> + 0
0x00007FF774D2C219 - ???W <unknown> + 0
0x00007FF774D2C272 - ???W <unknown> + 0
0x00007FF7751B4097 - ???W <unknown> + 0
0x00007FF7751FEC8D - ???W <unknown> + 0
0x00007FF7751EE212 - ???W <unknown> + 0
0x00007FF775209BED - ???W <unknown> + 0
0x00007FF7751EFEB6 - ???W <unknown> + 0
0x00007FF7751E6D00 - ???W <unknown> + 0
0x00007FF7753B2829 - ???W <unknown> + 0
0x00007FF7753ADE41 - ???W <unknown> + 0
0x00007FF7753AADA2 - ???W <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x00007FF774340000 ***
Loading VI Heap, HeapClass "FPHP", C:\LabVIEW\Projekte\Dev\V_View\V_VM001A_ViewManager\src\lib\A_MA001I_MainApplication.lvlibp\A_MA001I_MainApplication Messages\i_init Msg\Do.vi\9ef47adc-f318-494c-9b8b-6df3216d6863.vi
*** End Dump ***

I have now looked through the affected message chain but I cannot identify any enum in that way. The noted i_init Msg should not be executed at that time and also does not contain any enum.

Unfortunately I have no idea what OMUDClassLinker.cpp(5073) or AB_Build.lvclass:Open_Top_Level_VIs.vi are doing, so this does not help me by finding the error.

I would be really grateful if you have an idea what the root cause could be.

[CaseyM]

Well that sounds frustrating...

Can you share the code? I could maybe see if I can recreate the issue on my own VM.

Does this code call 3rd party DLLs or do anything else "out of the ordinary"?

[Jenso]

That would be great. Luckily I am still under the upload limit 🙂 It is running in LV2021 64 Bit

The ones out of the ordinary are
- .net XML Linq library (which is inside Windows .net Framework, was introduced about 3 months before this problem occurred and always worked quite well)

- a packed Lib version of the ActorFramework (this one worked now very well for about half a year of development, so I would say it should be ok)

To reproduce this error you have to follow this:

0. Start dev/testEnv_Launcher

1. Various Actors should start including the MainViewGeneric

2. User clicks on Close MainApp Button in MainViewGeneric

3. Application closes correctly

4. After restarting testEnv_Launcher not all Actors start correctly. After a timeout of some seconds suddenly everything (including the IDE) closes without warning

5. When restarting the IDE the window "Select files to recover" occurs

The changes after which this occurred is basically the following messaging chain:

1. V_MV001A_MainViewGeneric:Actor Core.vi -> Event triggers and sends V_VM001I_ViewManager:i_requestAppShutdown.vi to V_VM001A_ViewManager

2. V_VM001A_ViewManager:i_requestAppShutdown.vi sends A_MA001I_MainApplication:i_requestShutdown.vi to A_MA001A_MainApplication

3. A_MA001A_MainApplication sends Normal Stop.vi to itself.

If you need any more information, please let me know and thanks in advance!!

[CaseyM]

OK, I followed your instructions (thanks for the detail) and mostly saw what you said I would. It took me a few more runs before the application crashed, but I did see that after the first run, not all the actors launched properly.

On that note, it looks like the Station Manager loads but doesn't actually run. (See the state of the Run Arrow below.)

Anyhow, I don't know that I have much more time to investigate this right now, but my initial guess at what's happening is that some resource isn't be closed properly and so it doesn't launch correctly either the next time it's run. I'll try to revisit this more later, but hopefully that leads you on the right path.

[CaseyM]

Here's another potential clue...

The screenshot of the Station Manager I posted? Sometimes it does launch as "Running". And when it does that, that's when I see the program crash. When it doesn't run, the additional windows don't launch but it also doesn't crash.

So what does this tell us? I can think of 2 things for now:

1. There's possibly a race condition that prevents the Station Manager from launching sometimes.
2. Since it seems like the Station Manager launches other Actors, I think it might be one of those other Actors that's the problem child. Where does the Station Manager launch those other Actors?

Since you have source code that you can share that can pretty reliably recreate the issue, I'd suggest passing this onto NI Support at this point. Darren and his team can probably debug this much better than I can at this point.

[BertMcMahan]

I don't have the time right now to dig into your code, but one issue I've had in the past relates to relaunching actors and could be worth looking at.

When an actor is first launched, it goes into memory as "fresh" as if you'd just loaded it in the Project Explorer. Let's call that one Instance 1. If that one is still running, and you launch another (Instance 2), then that one will be "fresh" as well.

If Instance 1 closes, then you try to launch a third one, it will reuse the memory space of Instance 1. Things like "First call?", uninitialized shift registers, etc do NOT get reset to a "clean" state. You may even still have values in indicators. I suspect this is the standard behavior for "Shared clones" reentrancy but I haven't dug into it outside of AF.

Are you depending on some reference being un-initialized, or perhaps using First Call? to try to determine if you need to grab a reference to some external thing? If so you're almost guaranteed to have issues, and it'll be a massive PITA to debug since you only sometimes see it (when sharing an old clone with a particularly unfortunate set of "state" variables.

I've taken to calling "Reinitialize to Default" on the front panel of Actor Core's that have GUI's on them, and have made sure to always initialize my shift registers. Also, I've literally never used First Call? and not regretted it later, and it's worse in AF.

[Jenso]

Ok, that is very interesting. Actually I saw this bad initialization behaviour of shared clones already on some other place and I somehow feared to have it here aswell.

In my initial virgin understanding I thought that the same memory space is used but that LabVIEW would then take care of that cleaning itself. As you report it this might not be the case.

I actually think I already implented not using First Call? and initialized Shift Registers so far, but after you mentioning this I will recheck that with a focus on that. Thanks so far!

[Jenso]

Thanks a lot for your investigations. I think I will really make this step and send this for debug. In the meanwhile I will have a close look at the StationManager.

Thanks a lot again for you support!!

[Jenso · Accepted solution]

Ok, thanks to your hint I had a look at a different part of the code and I found the root cause.

Due to an unknown reason I was able to build a packed library although a VI was not executable. Inside this VI another VI was called but not found because of some filename issue. At that time a successful build of the packed library was no longer possible.

After relinking this VI I was then able to rebuild this packedlib, distributed it and voilá everything was working again.

Phew, that was quite some kind of searching... 😅

Thanks again for your support!

[CaseyM]

Glad you figured it out!