Microsoft Visual C++ Runtime Library Crashes

[John_Morrissey]

We've been seeing intermittent LabVIEW crashes when calling VIs through the LabVIEW adapter in TestStand. Code is similar on other test stations we have, but we run many more threads in this case than others where we havent' seen the issue.  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:

I get a dialog saying “Microsoft Visual C++ Runtime Library”

Program: …iles (x86)\National Instruments\LabVIEW 2012\LabVIEW.exe

We see these crashes intermittently on a PC that are running Windows 7 - 64 bit. Here is the data related to those PCs.

OS: Windows 7 Professional SP1 64 bit
LabVIEW: 2012 SP1 (12.0.1f5) 32 bit
TestStand: 2010 SP1 (4.5.1.144) 32 bit
PC: Dell Optiplex 9020 with Intel Core i5

Has anyone else seen similar issues? Any thoughts on how to isolate this to a certain application or piece of code?  Any help would be appreciated.
John

[TheCaptain]

John,

You say these crashes are intermittent...what's the approximate timeframe? Is it predictable (every 2nd/3rd execution) or does it occur around roughly the same timeframe?

When did these crashes start occuring? Did the system (TestStand + LabVIEW+ lots of threads) work at some point previously? If so, what changed? Was it just an increase in thread count? Can you run any of the multithreading examples successfully?

[John_Morrissey]

HI Kirk,

Sorry I didn't respond sooner.

I've been through quite a bit of debug already and looked at things like timeframe etc. I've also disabled anti-virus SW and the usual stuff like that. I know where it occurs and the code that's calling it, but it works fine in smaller batches. The issue appeared when I expanded my batch sizes in TestStand. I went from around 12 units in a batch to 24. I will continue to look at the particular piece of code, but it appears ok.  I guess more specific questions for you would be:

1) Does this particular "Visual C++ Runtime" error have any significance?

2) Any issues with LV 2012 SP1 f5 that were fixed in later versions that might be associated with this error specifically? I don't want to upgrade now since all of our code base is on LV 2012 and I would be out of sync and it would have to be a last resort.

3) We're still using LV32 and our OS is Win7 64. IT's never been a problem before, but if I do upgrade, should we now go to the 64 bit version? Back when we went to LV2012 there were drivers that were incompatible so we stayed with the 32 bit version.

Thanks,
John

[PhillipBrooks]

While searching for the error message, it seems like a common NI issue is the timing of allocating and releasing resources.

If your LabVIEW references are managed in TestStand, you might be running into a race condition.

https://www.dmcinfo.com/latest-thinking/blog/id/58/labview-tdms-write-close-issue

[John_Morrissey]

Hey Phil,
Thanks for the response.

That situation and behavior sounds exactly like my situation with the exception that I'm not using TDMS, rather we use User Events in the VI where the crash occurs.  I'm not familiar with TDMS, but I wonder if they share lower level code that might blow up in the same way.

We were focusing on a race condition also and this seems to support that theory. To avoid this I put in a polling loop to verify a dynamically called VI was closed before continuing. I logged the attempts and I'm seeing that sometimes it doesn't close right away (sometimes takes up to a 100-200 mS), but even if I wait, I still see the crashes.

I'm going to dig a little deeper here.  
John

[PhillipBrooks]

Are you using mixed dynamic and static event registrations?

https://lavag.org/topic/9986-out-of-order-events-is-not-a-bug-sort-of/

[John_Morrissey]

Hmmm.  Interesting thought.  I am going to add some variability into the state when I create my user events to test the theory that this is the cause.  Should be easy enough to do.

How/why did you connect this issue to the runtime crashes?  It would make sense because I do create groups of events asynchronously and didn't see this issue in LV 2014.