LabVIEW Access Violation Crashes from TestStand

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 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 TestStand and LabVIEW 2011 32 bit versions?  I posted this question in the LabVIEW discussion forum, but I don't know where the issue resides, I'm posting in the TestStand forum also.
Any information would be appreciated.
John Morrissey

Answer 1

I just had the same error in a LVOOP Project. First I got a crash (something with out of memory). The I got subsequent Access Violations. Could trace it down to one VI that:
a) had been working just fine before
b) wasn't changed after test mentioned in a) but got (even just running on its own) subsequent access violations every time I ran it
c) VI used a class konstant, property node (to set 2 class attributes); Inputs were a string and an integer and an error cluster; outputs: one instance of the class (initialized with string an integer) and the error cluster
d) Problem could be solved by deleting the class constant used in the VI and put the same in again (an just rewired the thing); I assume this caused a recompile that solved the prob
Maybe this helps narrowing the general problem down.
P.S: I dont have a still non working version of that VI, since I was happy to have solved this and just saved the VI before thinking about making a copy.