.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.

[GaryN]

So, it seems most of the issues were ours, but the tools couldn't really point us to the real issues, and it took a lot of extra debugging (crash logs, mem dumps). A few things that helped me:

1. I had to load and build a dummy PPL with all my dependencies one by one to see which one caused the issue. Once I knew what caused it, I was able to investigate and see that one of the dependencies down the line a few levels were dependent on a Framework DLL and that was enough to kill the LabVIEW process during compile.
   1. There's a setting in the INI file to disable Framework support and that helped pinpoint the assemblies that had dependencies on .NET Framework. (I also used a lot of dotPeek.)
2. The way .NET8 and dependencies work was an issue if all of the source dependencies aren't marked to be copied/included or otherwise present in the output location. I could have everything working in source, build and copy all the "true" dependencies to the output folder and still get a broken PPL. This is because I needed the dependencies' dependencies. 
3. There are some things, to @Kyle97330's point earlier, LabVIEW 20225 Q3 just doesn't support yet. One of those things is .NET Core controls. So, things like the PictureBox or the WebControl don't work if you want to use .NET8/Core (we use both). I also still am having trouble building one or two PPLs and none of the previous tricks I've been using are helping me figure out what's wrong so far.

All in all, we were able to get a lot of things done, but it's been a bit of a struggle. Hopefully 2026 Q1 will close a few more gaps. Not sure what our final solution will be at this point.

Thanks.