Crashing in Labview Runtime 2019 (Windows Error 1000)

[M@tt]

Hello,

I have a persistent crashing issue using an executable made using LV2019 SP1 on LV Runtime 2019. The program usually crashes within 8 hours and sometimes on startup so I don't suspect a memory leak. Additionally, this program has run for weeks on another PC without crashes using the same installer. I get a generic Error 1000 with my executable as the faulting application (see below).

I realize this is borderline just an IT problem, but I'm specifically wondering if there are common compatibility issues or windows/BIOS settings that come to mind that may need to be changed for LV to not crash.

Thanks for your time!

PC specs:

Windows 10 Pro 22H2, CPU i713700, MoBo Z790 PG Riptide, GPU GTX 1630 Aero.

Troubleshooting steps so far:

-MemTest86

-Intel CPU Diagnostic tools

-Reinstalled/updated all drivers to the newest version (except the RAID driver).

-Reinstalled LV runtime engine and the executable.

Error:

Faulting application name: ObserVAR.exe, version: 1.1.6.144, time stamp: 0x5d765dbb
Faulting module name: lvrt.dll, version: 19.0.1.4009, time stamp: 0x619b699b
Exception code: 0xc0000005
Fault offset: 0x0000000000c2fef1
Faulting process id: 0x31d4
Faulting application start time: 0x01dae846efe976fc
Faulting application path: C:\Program Files\AmpSci\ObserVAR.exe
Faulting module path: C:\Program Files\National Instruments\Shared\LabVIEW Run-Time\2019\lvrt.dll
Report Id: 5b71f202-6ec7-4269-b1ed-c1950c02b907
Faulting package full name:
Faulting package-relative application ID:

Thanks for you time.

[Kyle97330]

Does the program access any hardware?

If so, which hardware?  How is that hardware connected physically (GPIB, serial, USB, Ethernet, PCIe, etc.) and via software (VISA, DLLs, ActiveX, etc.)?

The more "integrated" a piece of hardware, the bigger chance that LabVIEW interacting with it could cause problems.  Hardware using USB or PCIe are much more integrated than a serial device is.  Hardware using DLLs or ActiveX is much more likely to cause fatal problems than VISA.

If you don't control hardware, or only control things over fairly disconnected means, then it does start to likely cross into the realm of an IT problem.

[M@tt]

This system does communicate with two hardware systems over ethernet and uses a NIC (00FCGN 5720), with one physical port dedicated for the network using each hardware system. Neither system uses software packages external to LabVIEW. One system uses TCP/IP communications, while the other system uses Ethernet/IP to communicate with a PLC system. I *think* we have used the same NIC card model in other computers with different builds of this software, however, I can't be sure right now. We have seen some network connection errors pop up with the PLC system, these errors are infrequent and don't appear to directly cause the software to crash. The software handles these errors and logs them:

ERROR: -251723767 --- EthernetIP Tag Read BOOL.vi;
Details: Unable to connect to the network path specified

ERROR: -251723752 --- EthernetIP Tag Read REAL.vi;
Details: The request response was not received in the requested timeout period

[rolfk · Accepted solution]

Exception code: 0xc0000005

This is an access violation error. This is a low level error generated directly by the CPU/Memory Managment Unit when an address is accessed that is not in the currently valid range and allowed access mode for the process in question.

As such this is pretty low level error and usually hints at some corruption somewhere. It could be a damaged driver, dll or executable file. It also could be a programming error/bug in one of the software components, but then it would generally occur anywhere and not just on specific computer systems.

The most common reason for this error:

- Outdated system drivers

- Corrupted files

- incompatible hardware or software versions

- Malware

- Faulty hardware such as RAM or harddisk