LabVIEW Access Violation Crashes from TestStand

[John_Morrissey]

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

[dug9000]

This issue is most likely due to something the VIs are doing that is either not threadsafe or is otherwise incorrect. Do any of your VIs call into dlls? Calling into dlls can lead to subtle problems like intermittent crashes if the prototypes are not specified exactly correct. Really this is just a guess though. You might try seeing if you can come up with a test case that makes the problem happen reliably and if so, start trying to narrow down what is required for the problem to occur. Or if there is a set of files you can send us to reproduce the problem we can take a closer look.

Hope this helps,

-Doug

[John_Morrissey]

Hi Doug,

Thanks for the reply.  None of the VIs are calling DLLs and I've been trying to narrow it down as you've suggested.  We were using LabVIEW Events in some VIs and replaced them with old fashioned globals, but the issues are still there.  It's strange in that it seems to happen randomly, but that could just be pointing me to a low level VI that a lot of the modules have.   Somewhere else I read about unreleased handles, but I can't find a way to detect them, other than search through the code.

John

[V_T_S]

I have noticed this many times. The root cause in my case was if the LabVIEW Adapter is set to runtime then by just selecting a step in Sequence File with LabVIEW model used to cause Access violation error.

[Al.B]

Hi John/Vidula,

In order to investigate the root cause of this issue, we'd like to take a look at the LabVIEW crash information.  Please attach the latest crash information file to this thread.  The file can be accessed from the LabVIEW crash dialog by clicking the "View Report" Link.

[John_Morrissey]

Hi Vidula,

That sounds like the same result, but a different cause.  In my case I'm just running a sequence and the crash occurs.   My default adapter is set to the LabVIEW development system. 

Based on a suggestion that it might be security or privilege related, I tried changing my user login (to one with PC admin privileges).  That seemed to help as I didn't have a crash for several days, then it crashed twice today.  It happened on 2 PCs around the same time and when our network was running very slowly.  I wonder if that is related.

John

[John_Morrissey]

Al,

I will do that the next time it crashes.  I have some old ones from the last few weeks, but I don't remember where they're kept.

John

[John_Morrissey]

I found the crash logs on my test station and attached the most recent one I saved (from last Friday).  I have several more and will keep them all in the future.

John

[John_Morrissey]

Just had another crash and here is the log for that one.

[Kiesch]

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.