LabVIEW Access Violation Crashes

Question

We've been seeing numerous LabVIEW crashes when calling VIs through the LabVIEW adapter in TestStand.  I've searched the knowledge base and discussion forums without success and figured I would post here before opening a help request.
The actual error we see is:
Exception: Access violation (0xC0000005) at EIP=0x012B60E6  Version: 11.0.1f1
We see these crashes several times a day, but while calling no specific VI.  They happen mostly on 2 PCs that are running Windows 7 - 64 bit, but I think we've seen them in the past on PCs running the 32 bit version of Windows 7. Here is the data related to those 2 problematic PCs.
OS:  Windows 7 Professional SP1 64 bit
LabVIEW: 2011 SP1 (11.0.1f1) 32 bit
TestStand: 2010 SP1 (4.5.1.134) 32 bit
PC:  Dell Optiplex 790 with Intel Core i5
Other significant information.
We see these crashes when we're running the batch model in TestStand with multiple threads open.  Some VIs are reentrant, and some are not.
The 2 PCs that run the batch model (with multiple threads) have the 64 bit version of Win 7 Pro, and crash most often.
The 3 PCs that run the sequential model or the batch model with a single thread have the 32 bit version of Win 7 Pro and rarely if ever have crashed.
Not sure if it's related to the OS version or the multi-thread usage and switching the PCs/OS versions to isolate that isn't easy.
Has anyone else seen similar issues?  Does Windows 7 Pro 64 bit work reliably with LabVIEW 2011 32 bit? 
Any information would be appreciated.
John Morrissey

Answer 1

Hi Amezam, thanks for your reply.
We appear to be having different access violations each time (or they are one of a large group of them, we cannot tell).
The crashes appear to be at random, we cannot connect the crashes to any specific sequences of events and we cannot reprocude the crash consistently on the same piece of code! One pattern I have noticed, however, is that the violations appear to coincide with a peak in program activity - very frequent indicator updates for instance*.
I am unable to disable antivirus protection at will, but I will raise it with our IT Support to see if we can try that.
I believe that we are intearacting with external code - 3rd party device drivers which include packed libraries. I have no control over these and, furthermore, if I were to remove them the code would not be able to function at all. However, if you think it is a good idea I can attempt to create a separate piece of code which calls the same driver function very rapidly to see if that is the problem.
As for error handling - those nodes which use them only return error codes from the base 3rd party libraries, which according to the documentation only return custom error codes (these are not related to the error/crash that we are seeing). If you think it's still possible that they will return an Access Violaton error and crash, I will link them up.**
* - sidenote: I implemented a method of reducing the number of updates to a graph indicator (from several times a second to several times a minute) - this has reduced the problem significantly.
** sidenote 2: Some of the nodes which return custom errors are linked properly, and they are not returning errors; these ones are the most likely to return errors since they are called extremely frequently. I am not seeing anything except the documented custom error codes from them.