LabVIEW 2025Q3 .NET core memory leak!

[Cloedu72]

I have discovered that LabVIEW 2025Q3 has a .NET memory leak. It doesn't matter which method you call from any class, a few kilobytes are lost every time. When large amounts of data are transferred during the method call, it happens faster, but the underlying problem remains.

I tried explicitly calling the garbage collector in .NET, but that didn't help. Within a few minutes, the memory in LV2025Q3 32-bit fills up and an error message (Memory full) appears.
=> Memory leak of approximately 4.2 kB per call (current example)

I borrowed the example from a forum member who demonstrates the problem using a very simple example. (https://forums.ni.com/t5/LabVIEW/net-8-labview-2025/m-p/4433787)

a few minutes later.....

Is there a workaround, or will NI consider this a bug?
=> I did not observe the same behaviour with .NET Framework....

Claude

[Cloedu72]

Any ideas or similar experiences? It seems as if no one is using .NET Core?

[Yamaeda]

What happens if you send the .NET reference through a shift register? I had a similar experience with an ActiveX program where too many calls caused a crash. In that case reusing the reference reduced the issues.

[Cloedu72]

Yes, that leads to the same problem. I have tried almost everything in the real application. This is just a simple demonstrator that is reduced to the essentials.

[jyoung8711]

I think this is pretty concerning. 4 kB per call could definitely add up quickly.

[Cloedu72]

I have also submitted a service request to NI. NI is currently working on this issue and the support has now forwarded it to R&D. Hopefully, the fix will be added in Patch3!

[Cloedu72]

I just received the following message from NI:

******

I’ve just received an update from our R&D team, and they have confirmed that this is indeed a bug. The team has started working on a fix; however, they were unable to provide a timeline for its release at this stage.

In the meantime, the recommended workaround is to downgrade to LabVIEW 2025 Q1, which avoids the .NET memory leak. We have tested the same code on LabVIEW 2025 Q1 and can confirm that the issue does not occur in that version.

******

Unfortunately, that's not an option for me, as we use .NET callbacks... I'm really disappointed and hope we find a solution soon!

The current state of the .NET implementation is not usable for a productive system!

[jyoung8711]

That's... a terrible workaround.  The .NET core implementation in 2025 Q1 was REALLY bad, essentially unusable for all but the simplest of examples (even now there are quite a few issues -- See this thread: https://forums.ni.com/t5/LabVIEW/State-of-Net-Core-in-2025Q3-Bugs-and-Errors/m-p/4454466)

Does this memory leak affect BOTH .NET Framework & Core in Q3? or just Core?

[Cloedu72]

"Does this memory leak affect BOTH .NET Framework & Core in Q3? or just Core?"

The problem only occurs in .NET Core.

[jyoung8711]

If that's the case, then I think the suggestion to go back to 2025 Q1 is really... weird advice since the .NET Core support there is barely half baked. 😞

I'm glad they identified it as a bug, but this is pretty limiting... would be nice to see a fix relatively quickly here.