LabVIEW crash suddenly without errors while VI is running

[Boss-Hogg30]

Hi everybody,

I am using LabVIEW 2020 32-bit version 2020 f2, with which I developed a VI (composed by some others subVI's) that interfaces with a power instrument via VISA (I have NI-VISA 20.0.0). At first, I run my VI and it work properly, but at certain random point (after some hours of running, not ever the same amount), LabVIEW closes suddenly without any error message. As reported in the page "Troubleshooting LabVIEW Crashes" of NI, I used WinDbg to monitor LabVIEW execution. When LabVIEW crashed, WinDbg gave me this message:

Critical error detected c0000374
(4ec0.4cec): Break instruction exception - code 80000003 (first chance)
eax=00000000 ebx=00000000 ecx=c0000374 edx=0987a6d1 esi=00000002 edi=0ff18358
eip=77d47012 esp=0987a840 ebp=0987a8cc iopl=0 nv up ei pl zr na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000246
ntdll!RtlReportCriticalFailure+0x4b:
77d47012 cc int 3

There is enyone that can help me? thank you very much.

[GerdW]

Hi Guiseppe,

it really would help to attach your VI(s)…

When VIs crash "after some hours" then most probably the reason is within those VIs!

[Kyle97330]

The sort of crash over time and such that you describe sounds like the sort of thing that could be caused by a memory leak.

I would advise looking in your code (and subVIs) for any place that might be a reference of some kind that you're opening and not closing.

Additionally, if you're calling any external code (DLLs, ActiveX), see if there's any Dispose() or Close() methods that might need to be called on those objects.

[Jacobson-ni]

Does WinDbg give you a call stack? You won't have the PDBs to get specific information from any NI functions but it should at least tell you the DLLs being called which can sometimes be helpful pointing to general areas you might want to investigate further.

[Boss-Hogg30]

Hi Keyle97330, I am investigating precisely this kind of issue. These days, I used LabVIEW Desktop Execution Trace in order to see where can be the problem. I have acquired the memory activity with a threshold of 0 Byte (so I should be acquired all the memory activities). I do not see any activity in which memory usage is growing.

I see lots of memory resize, some memory allocations and memory free. Nevertheless, I see something strange: I see one of my subVI's in which the total memory free is more than the memory allocated, but I don't know what it means. I must specify that in this subVI I have essentially only a TDMS Write function, in which the corresponding TDMS Open function has the buffering enabled. In fact, I noted that if the buffer is disabled, the crash comes earlier. Regarding memory resize, LabVIEW do it many times for different subVI's but in every cycle in which my code is repeated (composed by while timed loops) the sizes and the resizes are the same, so every VI begins a cycle with a size and ends with another size, but every time they are the same.

Anyway, I checked the opening and closure of the TDMS file reference but seems to be all good. I checked even if there is any array which changes size during the execution, but nothing.
I used even Windows Performance Monitor, in which, I see that especially the Pool paging bytes are slightly growing through the code running. I did that because I read something about crash problems that Windows 10 shows if the Paging Memory is free to change, for which Microsoft advice to set a fixed dymension. I am going to try this next time.

Unfortunately the VI is really complex and big so I cannot share it with you. Could be useful if I share the acquisition from LabVIEW Execution Trace Toolkit? I acquired the last 100000 commands executed before the crash. From what I saw, the execution of a cycle shuld be composed by about 200 commands.

Particularly, in the LabVIEW Execution Trace Toolkit file (.det) the VI with the strange behaviour is "TEST_MEAS_Write-CloseFullFile_Logic_K_NOSLMD (SubVI).vi" (Sorry for the long and strange name). I share even a .xlsx.

Thank you very much for your help.

[rolfk]

The break you see is really a debug breakpoint that the code execution seems to run into. This can happen when the code execution goes into unintended code paths as the compiler can sometimes add such statements in the compiled executable where it determines that the code never ever should get into. Or someone, somewhere left a DLL or object module in debug mode.

I only have seen this myself with third party DLLs, including my owns, but never really with NI released software. Are you using anything non-NI in this application? Especially something that comes with its own DLLs in the form of drivers, including .Net assemblies?

I see in your last post that you suspect it to be related to TDMS file writing. That is one area I have very little experience with. In my 30 years of LabVIEW programming I have used TDMS about twice. There were lots of stability problems in the beginning and somehow that experience made me shy away from it. It has been improved a lot since, but as they say: Fool me once, shame on you, fool me twice, shame on me.

[Boss-Hogg30 · Accepted solution]

Dear all,

I apologize for writing to you so late. I fixed the problem. After some research I found that Windows 10 had some issues regarding the dynamic changing of paging memory, as reported in this site: Memory allocation errors can be caused by slow page file growth - Windows Client | Microsoft Learn.
For this reason, I fixed the memory at 1.5 times the physical RAM memory. It prolonged the duration of the LabVIEW execution but didn't fix the problem. So I turned off all the useless background activities of the computer. After doing that, I definitely fixed the problem and the execution didn't stop anymore. I think the real guilty was the antivirus, but I don't know for sure. So thank you very much for your support!