10-29-2012 05:49 AM
@amezam wrote:
Hello P Anand,
Please see the post I did earlier to Stoove. Please let us know if it solved by cleaning the PC.
Best Regards,
Sorry for the Delay.
Clearing the PC didn't work well and still we were getting the same error.
We replaces the ActiveX server registery and also replaced the main python core files that we were accessing and till now we haven't got any Access violation error.
10-29-2012 08:02 AM
Last week we finally found a solution to our version of this problem!
In our particular case, we found that the crashes were due to our use of the "Build Array" vi. It appears that some aspect of the manner and frequency with which we were calling it caused it to erroniously write to the memory. Although the NI engineer I spoke to didn't go into detail, it appears that it was not as stable in our case as alternate methods.
Our solution was to modify the method with which we built an array. Instead of building the array from rows of data at the time they are acquired, we now initialise the array to the final size and use the "Insert Into Array" vi to place data at the correct index. This is much less convenient but significantly more stable for us. Since the change, the number of Access Violations has been negligible in comparison to the frequency of use of the code.
I'd recommend taking a look at any fixes similar to this if nothing else is working.
Thanks to everyone who suggested fixes!
10-31-2012 06:40 AM
One more scenario for the Access violation problem (Original thread)
11-02-2012 11:58 AM
@Stoove wrote:
Last week we finally found a solution to our version of this problem!
In our particular case, we found that the crashes were due to our use of the "Build Array" vi. It appears that some aspect of the manner and frequency with which we were calling it caused it to erroniously write to the memory. Although the NI engineer I spoke to didn't go into detail, it appears that it was not as stable in our case as alternate methods.
Wow, that sounds like a potentially terrifying bug.... Build array not being watertight? Say it isn't so....
Shane.
07-18-2013 09:45 AM
The same thing happened to me but it only worked for a few months and then I started seeing it in 2012 also.
08-06-2013 06:54 AM
Hello,
I am also experiencing this problem. But in a very specific situation. My LV programs work just fine. But I need to build applications. When I run these applications, they also work fine, but when I quit them (using red cross or menu File - exit) I get crash report - Access Violation. I tried this with LV 2012 SP1, LV 2013, on different computers, with antivirus turned off and I get still the same result. EIP address remains the same, different for different computers. In my programs I use dll libraries for communication with external application - communication server.
Do you have any idea what can be causing this? Thanks for your advice.
08-07-2013 06:28 PM
I looked up our previous service requests and one LabVIEW developer was able to solve this by creating the exe on another version of the Application Builder. If you have access to another version of LabVIEW Application Builder then it might be worth it to give it a try.
I'm not sure what could cause this. Perhaps it is some kind of corruption?
Jeremy P.
04-22-2014 06:14 AM
I get the following error : Exception: Access violation (0xC0000005) at EIP=0x776ED583. Help me out
04-22-2014 06:25 AM
The fix for our issue was incorporated into LabVIEW 2012 SP1. We have rarely if ever seen the problem since.
04-22-2014 06:48 AM
In my case, there was a problem with call library function node. I set external library file location inside function properties and it caused this error. After changing it to setting by external string constant it worked. Don´t ask me why.... 🙂