Build LV App Crash after hours of operation (LV2025Q3 ?)

[nottilie]

Dear communitiy members.

I have a big problem since i upgraded form LV2025Q1 to LV2025Q3 but i am not 100% sure of just this upgrade caused my new poblems.

I also did some really minor changes to my code.

The build application typically runs about 5 hours without any problems or memory leaks. I tried a lot of things in the last few days to solve the problem without your help 😉

After this time the Application disappears. 

Windows event viewer always shows the same entries corresponding to this crashes.

First is a .NET null pointer or similar error shown like this.

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

- <System>

  <Provider Name=".NET Runtime" />

  <EventID Qualifiers="0">1026</EventID>

  <Version>0</Version>

  <Level>2</Level>

  <Task>0</Task>

  <Opcode>0</Opcode>

  <Keywords>0x80000000000000</Keywords>

  <TimeCreated SystemTime="2025-09-08T14:20:04.8648462Z" />

  <EventRecordID>121437</EventRecordID>

  <Correlation />

  <Execution ProcessID="22128" ThreadID="0" />

  <Channel>Application</Channel>

  <Computer>CLIA087.ionicon.local</Computer>

  <Security />

  </System>

- <EventData>

  <Data>Anwendung: TOFACQserver.exe Frameworkversion: v4.0.30319 Beschreibung: Der Prozess wurde aufgrund einer unbehandelten Ausnahme beendet. Ausnahmeinformationen: Ausnahmecode c0000005, Ausnahmeadresse 0000000000000000</Data>

  </EventData>

  </Event

The second is then the corresponding appcrash error.

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">

- <System>

  <Provider Name="Application Error" Guid="{a0e9b465-b939-57d7-b27d-95d8e925ff57}" />

  <EventID>1000</EventID>

  <Version>0</Version>

  <Level>2</Level>

  <Task>100</Task>

  <Opcode>0</Opcode>

  <Keywords>0x8000000000000000</Keywords>

  <TimeCreated SystemTime="2025-09-08T14:20:05.2721160Z" />

  <EventRecordID>121438</EventRecordID>

  <Correlation />

  <Execution ProcessID="43696" ThreadID="29132" />

  <Channel>Application</Channel>

  <Computer>CLIA087.ionicon.local</Computer>

  <Security UserID="S-1-5-21-2945132141-4116781341-2805852645-8617" />

  </System>

- <EventData>

  <Data Name="AppName">TOFACQserver.exe</Data>

  <Data Name="AppVersion">4.4.116.65</Data>

  <Data Name="AppTimeStamp">688a02f1</Data>

  <Data Name="ModuleName">unknown</Data>

  <Data Name="ModuleVersion">0.0.0.0</Data>

  <Data Name="ModuleTimeStamp">00000000</Data>

  <Data Name="ExceptionCode">c0000005</Data>

  <Data Name="FaultingOffset">0000000000000000</Data>

  <Data Name="ProcessId">0x5670</Data>

  <Data Name="ProcessCreationTime">0x1dc20a45a6bb706</Data>

  <Data Name="AppPath">D:\Ionicon Applications\test\TofACQserver\Application\TOFACQserver.exe</Data>

  <Data Name="ModulePath">unknown</Data>

  <Data Name="IntegratorReportId">7cc5e665-2ce6-46c2-83d9-90527590771a</Data>

  <Data Name="PackageFullName" />

  <Data Name="PackageRelativeAppId" />

  </EventData>

  </Event>

The simple question is. Do you think this can be due to the update to LV2025Q3 or is there a "relatively easy" way to find the origin of the problem.

In my last tests is shrinked the application to a status where no .NET assemblys are used but the .NET runtime error still happens. 

This makes me really wondering.

Thank you for any suggesstions.

P.S. It is a relatively big application with a lot of external hardware access via manufacutureres driver DLLs and CLNs.

Which was working without any problems before and now just for 4-6 hours.

[Yamaeda]

I had a similar problem with a program. In that case it was too many open/close references, it turned out to be a limit of 1 million times in Windows (or it never reclaimed the memory). I restructured it to keep the references open and reuse them instead.

[nottilie]

Thank you Yamaeda

I checked with DETT if there is a memory leak. I even found a problem of not closed queue references and solved it.

But I am still skeptic. 

I typically use named queues, obtain it in my "main" loop and use it there. Many parallel loops are also using this. In this case they obtain the queue by name then read, preview, or write and finally close it so the main loop is still the "master owner". 

Can you imagine that it would be better to store the queue reference in a functional global instead of obtaining the named queue.

I do not see any differences if i close the queues correctly.

The fundamental question is if the .NET errors origin really comes from .NET framework, because in the project where I build the application there is no .NET assembly in memory, so my code does not use any .NET calls.

Thank you for now