.NET Core 2025 Q3 Compile Crashes

[GaryN]

We are upgrading our codebase from an older stack of NI products, LabVIEW 2022 and TestStand 2022, to the latest 2025. With that comes the need to support .NET Core/.NET Standard for our .NET assemblies. I've gone through the painful process of updating some of our assemblies that is used in one of our PPLs and can open all VIs in the library and they point to .NET Core assemblies only and are not broken. (We are targeting .NET Standard 2.0 on these assemblies.)

The issue comes when I try to compile the PPL. I get an error stating that one of the VIs (probably more than one, but the first one it sees) changes its state and fails

VI_NOTBROKEN (3): [VI "LVPackedLib.lvlibp:SubVI_Check.vi" (0x24e60e00)]
SetVIIdle on a previously viBad VI: vi=true

<DEBUG_OUTPUT>
1/12/2026 10:48:31.520 AM
DWarn 0xD4C1BA7F: Going from bad to good in the build context during app build![LinkIdentity "LVPackedLib.lvlibp:Check.vi" [ My Computer Build Context]
source\editor\BadLinkerObjs.cpp(659) : DWarn 0xD4C1BA7F: Going from bad to good in the build context during app build![LinkIdentity "LVPackedLib.lvlibp:Check.vi" [ My Computer Build Context]
[ExecSys:0; Executing:"[VI "AB_Source_VI.lvclass:Open_Reference.vi" (0x1956b828)]"]
minidump id: 9ebb0200-d139-4ca5-4c4c-2ef6d9230f77
</DEBUG_OUTPUT>

When this happens LabVIEW just flat out crashes, leaving open one or more instances of the NIDotNETCoreHostApp. Subsequent compile attempts fail to really even start unless I kill these processes, at which point the next compile attempt will subsequently crash again. Any ideas what the error could mean or anyway to get more information on what's actually crashing?

[billko]

I looked this up in Google AI search and the only suggestion worth pursuing is to clear the compiled object cache to get it to recompile. It does describe exactly what you are experiencing though.

[GaryN]

Thanks for looking into it. I tried that earlier and did it again for giggles after reading this and still get the crash. 

I was able to get a crashdump using some Windows tools and it looks like there's a memory access violation. I think I need to go through NI for help on this. I already have a ticket.

Thanks again for trying. If/when I get a response, I'll be sure to update the ticket.

[Kyle97330]

If you do a bit of searching in the forums for other reports on the 2025 .NET support for Core you will find other people with fairly major issues:

https://forums.ni.com/t5/LabVIEW/LabVIEW-2025Q3-NET-core-memory-leak/td-p/4456862

https://forums.ni.com/t5/LabVIEW/State-of-Net-Core-in-2025Q3-Bugs-and-Errors/m-p/4454466

I have yet to move to it myself but I feel that 2025 Core support isn't ready for full use yet.  If you can wait at all and continue to just use the old 4.8 Framework support in 2022, I urge you to do so.

[GaryN]

Yeah, I've seen a lot of the issues. We punted once before because of the constructor bug, so at least that's been fixed. The issue is we're supposed to stay relatively up-to-date with the releases (~3 years) and we're currently on 2022. There have been some bug fixes and issues we've run into and implemented workarounds for that have been fixed that we'd like to take advantage of, but this .NET issue is a big stumbling block. Not updating or just going to 2024 is still an option, but not the preferred one.