From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
LabVIEW
Access violation (0xC0000005) at EIP=0x0EC9F657
Hi all,
While running my program, LabVIEW windows shut down all, and the LabVIEW Crash Reporter pops up. The program is supposed to run for 10 minutes, but corrupts after running for around 20 seconds, same time every running.
There is a link talking about this situation. I tried to run as administrator, but it still happened at the same time. Some posts talking about their corruption when opening the program, or the very beginning of running. Mine only happen after a certain time. I am wondering if there are some possible reasons causing this particular corruption, before I re-install LabVIEW as suggested in the link above. I don't attach codes because you will need my equipment to run. Thanks in advance.
13.0.1f2 (32-bit) in Windows 10
I'm not saying this is the cause, but I want to point out that LabVIEW 2013 doesn't support Windows 10. Windows 10 support was added in 2015 SP1. As a result you might have a hard time getting support from NI since it wasn't validated on that OS.
@VictoryNeal wrote:
There should be a reason other than that, because the same edition works in others' project.
That doesn't mean much. You could just be unlucky enough that it doesn't work for you. Although, like everyone else here, I think it's probably not the cause.
Do you have dlls in your code? (They can be hard to find sometimes. Perhaps a driver?) Dlls - especially those not written specifically with LabVIEW in mind - may not work as intended and could cause issues like this.
@VictoryNeal wrote:
Yes, there are some DLLs with the program. How to solve?
You can't really solve it unless you can fix what's going on inside the DLL.
An Access violation is a very generic error. It is pretty much saying that something, somewhere in the application tried to access a memory location that Windows (actually the CPU) does not consider to be a valid memory address for the current process. That could be a bug in LabVIEW, a bug in one of the many DLLs your program tries to use or a bug in the LabVIEW interface VIs that access these DLLs. And that is not all, it could be also a faulty memory chip, a corrupted byte on your hard disk or something else.
While bugs in LabVIEW aren't unheard of, it is highly unlikely that such a bug would affect you and nobody else. If you use any form of DLL in your program, chances that the bug is in there (either in the DLL or in the interface to access that DLL) are about a zillion times bigger than a bug in LabVIEW. And yes such bugs don't need to occur on every computer. Memory corruption isn't always detectable. It could also silently corrupt the memory location where one of your measurement results is stored. Since this is a valid memory address in the process, it will not be caught by the CPU protection mode. But your measurement will be off (usually ridiculously), but if it is one of several 1000 or million of measurements, you may not even have noticed it yet (until the gasoline pump tested with your program isn't working anymore and will make the plane crash).
