LabVIEW Access Violation Crashes from TestStand

[John_Morrissey]

HI Kiesch,

That's interesting.  We were thinking that it was related to our communications interface (Ethernet), but I haven't been able to isolate it to that.  Then I noticed it in other VIs that don't do any communication so we were at a loss.

We've been struggling to find the root cause for this and haven't had any luck, then just this morning I heard back from an NI Applications Engineer and he thinks they might know the cause, but didn't give any details. In any case I will update this thread if I hear anything else as it sounds like several people are seeing the problem.

John

[John_Morrissey]

Here's an update to the original issue that started this thread.  After sending the crash logs to NI, someone looked at them and was able to trace the issue to the LabVIEW 2011 release we were using.  I wasn't given the full details about the bug or the fix, but apparently there was a stability issue and it was corrected in LabVIEW 2012.  Yesterday I installed LabVIEW 2012 and after some limited testing it appears that the problem is resolved for our multi-threaded failure mode.  So, if you are seeing a similar issue, it might be fixed by upgrading to LabVIEW 2012.

The migration to 2012 isn't a big deal for us since we don't have a big installed base, but I would be very upset if we did and they couldn't fix this with a patch to LV 2011.  I would also not be happy if we didn't have SSP and had to buy upgrades to our platforms because of an issue like this

[John_Morrissey]

Well that figures, as soon as we think the issue is gone, it reappears.  We ran for a day and a half with increased batch sizes and thought it was gone, but it just took a while to appear.  Preformance seems to be much better, but we're back at square 1.

[Perry_S]

Hi John,

Could you post this new crash dump file? The issue might be caused by something different this time. I look forward to getting the file.

Regards,

Perry S.

[John_Morrissey]

Hi Perry,

I just sent it to Al Billington who's looking at it also.  I will attach it here as well.

John

[TSNT]

Ironically, I just got a new computer, figured I'd go with 2012 instead of 2011 which was working excellent.... and I'm seeing those errors all the time when trying to just save vis....

[John_Morrissey]

I saw that also and then realized I was linking to VIs that had been moved or were compiled in the wrong version.  That said, it shouldn't cause the environment to crash.

John

[Kevin_F]

Hey John/TSNT,

Would you be able to post a VI that exhibits this crashing behavior when saving - if we can get the behvaior to reproduce in house it will make the debug efforts much easier.

[John_Morrissey]

Hi Kevin,

We see it in a number of different VIs, but that could just mean that there is a common subVI that's causing the problem.  I'd rather not attach it to a thread in an open forum.   I'm working directly with Al Billington and he can give you my email address. 

I will send you the VI that I see it most often in with additional information about the circumstances.

John

[John_Morrissey]

Oops, I didn't read the last post completely.  You were asking about VIs that crash "while saving". 

I didn't see that failure mode, but saw a crash when I loaded and ran TestStand and it was still pointing to my LV 2011 VIs.  After I fixed my search order that problem went away.