LabVIEW Crash to Desktop with code 0xc0000005 after running for various time periods, faulting module tdcore.dll

[Danny-251]

Hello!

I have a LabVIEW system that is controlling 2x serial instruments, 1x GPIB instrument (via an NI GPIB-USB-HS adapter), 1x ActiveX instrument, and 1x TCPIP instrument. Each instrument has its own control VI that I have previously developed for standalone instrument control. For this test setup, which needs all of these instruments to work together, I load each instrument into a subpanel of a 'master' VI, then perform actions via control references to run through my test sequence, which is a component life test that iterates once every 5 minutes, and theoretically should complete in ~1 week.

I am experiencing LabVIEW crashes while running this test at random points during the test. Sometimes the test will make it through 100 iterations prior to crashing, and sometimes it will only make it through 5 iterations prior to crashing. I get no LabVIEW crash report popups after the crash occurs, nor do I get any information in the "\Documents\LabVIEW Data\LVInternalReports" folder. Windows Event Viewer does log an 'application error' with each crash:

Faulting application name: LabVIEW.exe, version: 25.1.1.4001, time stamp: 0x67a1e491
Faulting module name: tdcore_25_1.dll, version: 0.0.0.0, time stamp: 0x67820aa4
Exception code: 0xc0000005
Fault offset: 0x0000000000080330
Faulting process id: 0x2078
Faulting application start time: 0x01db943285931148
Faulting application path: C:\Program Files\National Instruments\LabVIEW 2025\LabVIEW.exe
Faulting module path: C:\Program Files\National Instruments\LabVIEW 2025\resource\tdcore_25_1.dll
Report Id: 933790e2-5f67-4741-bd07-9fac39f474a2
Faulting package full name:
Faulting package-relative application ID:

Things I have tried so far:

• Different LabVIEW versions (tried with LabVIEW 2022 Q3, 2025 Q1)
• Checked for memory usage creeping up over VI runtime (none observed)
• Tried various OS troubleshooting steps (reloaded OS, changed from Windows 10 to Windows 11, changed control computers, ran memory diagnostic tools)
• Ran through test with different instruments disabled (still observed crash behavior, though this did seem to affect the duration of stability prior to crash. When I disabled my most 'active' instrument, the duration before the crash occurs increased significantly. This makes me think that whatever is happening may have something to do with the way I am controlling these instruments)

If anyone has any ideas they would be appreciated! Particularly, I haven't been able to find much info on the 'tdcore.dll' that the windows error points to.

I have attached screenshots of some parts of my code that characterize how I am controlling the instruments, as so far I feel like something with this methodology may be the source of the issue.

Thanks in advance.

-Danny

[Andrey_Dmitriev]

Look like internal issue. The strangest crash I have ever experienced in my career was due to an unusual interference between a serial port and... a network stream. Absolute independent things by design. Two dynamically called VIs tried to establish communications: one used VISA Configure Serial Port, and the other used Create Network Stream Writer. Each worked fine individually, but when both started simultaneously, they randomly crashed at runtime (and in runtime only, no any problems in dev environment) with an exception. When both were in the same VI, there was also no problem, but two SubVIs called dynamically caused a crash approximately every 10-15 starts, occurring sporadically. I solved this by adding a semaphore and putting both VISA Configure Serial Port, and Create Network Stream Writer into a critical section, but it was not easy to find (the whole app has around 7000+ VIs).

When you encounter such a crash, the only way to resolve it is to strip down the code step by step, removing pieces to locate the problem (when disappeared), and then avoid it with a workaround (your code looks at least "legal"). ActiveX also needs to be investigated. Any code involving DLL calls is inherently dangerous. Sometimes running under a debugger (like x64dbg or windbg) can be helpful. Without source code, you won't get much, but sometimes the call chain or surrounding context may give you a hint or idea of where to look for the trouble. Sometimes LabVIEW can drop a crash log file (somewhere in Documents\LabVIEW Data\lvfailurelog or Documents\LabVIEW Data\LVInternalReports\LabVIEW), which can also be helpful. It's a good idea to add some logging to trace execution shortly before the crash (I use OutputDebugStringA from kernel32). Then modify the code to implement a kind of workaround. If you have a minimal VI where this problem can be easily reproduced, you can ask NI for help, but a fix will take some time as usually. Based on screenshots only is hard to give more hints.

[Danny-251]

Thank you very much for your response Andrey!

Regarding the ActiveX instrument (a Thorlabs MFF101 flipper) - I have reproduced the crash without it connected, so I don't believe it is a contributing factor.

I am going to try and further narrow things down via some of your suggestions (which I really appreciate as I am new to troubleshooting internal errors). My LabVIEW project is fairly extensive and split into lots of individual VIs, which is why I only attached a few screenshots to my initial post. Hopefully if I can narrow things down a bit I will be able to provide more useful attachments.