Crash using open vi reference LabVIEW 8.6 (internal error)

[Al1234]

I have an intermittent problem that has recently started to happen more regularly but it's extremely difficult to debug since it is not consistent and the crash has no warning with  all the LabVIEW windows closed and nothing left to see in the task manager.

I have a launcher application that programmatically loads into memory, runs and stops, closes front panels and monitors the status of several stand-alone child VIs.

Occasionally there is a complete crash of LabVIEW with no warning Sometimes a dialog "Sorry LabVIEW has to close...blah blah blah..." or a screen lock-up.

With highlight execution on I can see that the fatal crash happens as "Open VI reference" runs - this is in a loop and the crash may happen on any iteration. (see capture.jpg)

As long as the program initialises and runs OK then it runs correctly for days.

The VI path is correct.

If I copy and paste the entire block diagram to a new VI the same happens.

I have snipped and attached part of the code from my complex program to try and simplify it for debugging - this code is no different from my problem code (that I can see!) but has never crashed!

Any help or workarounds would be much appreciated...

Al

I am using 8.6.1f1 on XP.

[systemcrash]

I do not see problem in my system, so when you are in highlight mode, when does the error occur, I mean which VI, VI-1 or 2 or.......

Write a new VI , and check opening VI ref one by one, Check for error each time, if you see LabVIEW crashing while opening the ref for VI "5" (say) then go check your "5.Vi" and correct accordingly.

[Al1234]

Sorry - you completely misunderstand the problem!

The attached labview file is a simplified bit of code that works perfectly. The capture.jpg is from my main program (too large to post) with exactly the same (?) functionality which occasionally fails with a LabVIEW internal error that makes LabVIEW crash sometimes with an internal error message and sometimes with nothing.

The path input to the "open VI reference" is correct and if I use the execution highlighting it is the instant that the highlighting reaches the "open VI reference" function that LabVIEW crashes.

Has anyone seen this before - it sounds like one for an NI apps engineer...

I'm desperate for a work-around.

Thanks Al

[systemcrash]

Understood your problem in your previous post, just suggesting you to try the method which I posted, I am not sure why LabVIEW is crashing, Instead of giving many Vi's as input at one time, try one by one and check your code is still crashing.

[Al1234]

It doesn't matter which path is input to the "open VI reference" the occasional error happens at the instant "open VI ref " runs. Normally it runs perfectly.

If the for loop is removed and only one VI ref is created it always runs OK.

This code is in an initialisation state of a large state-machine based application. If I remove the for loop and instead run this init state several times the same crash occurs.

I suspect it's something to do with storing references in an array in my mega-cluster. I'll try a few other methods of storing them and see if the problem goes away.

Thanks for your help - it's much appreciated!

Al

[Al1234]

Problem solved!

It was an interaction with the shared variable engine.

I originally had the shared variables auto-deploying with the project.

If I programmatically deploy the shared variables before my launcher VI starts and then wait until I read a shared variable without an error (This ensures that the library has been successfully deployed - I don't have the DSC module) then I don't get get the LabVIEW crash.

Sounds like a bug to me!

[Al1234]

Spoke too soon!

Still had intermittent LabVIEW internal crashes.

Work-around was to use an array of static VI references rather than "open VI references" see attachment.

Any ideas why this is happening??

[Al1234 · Accepted solution]

Still a few crashes - removed all shared variables and replaced with globals!

They were only passing environmental data between independent VI so It's a satisfactory solution.

Is the shared variable engine more stable under 2010?

Has anyone else had crashes while dynamically launching VIs containing shared variables?

Al

[langedrag]

Yes, I have experenced the same kind of problem when opening multiple VIs with data bound controls. When I open several VIs with data bound controls, I have to make sure that the data binding initialization is completed for each VI before loading the next VI. This is more tricky that it sounds, because there is no easy way (as I know) to determine exactly when it is safe to load the next panel. I solved it by only using data binding on custom made XControls which can report its data binding status back to a custom made panel loading API. The easy (but not so safe) way of doing this, is to put a delay between each time you are loading a VI.

The core of the problem is that the data binding initialization mechanisms does not seem to be "thread safe", and will in best case slow down the performance when loading multiple panels, and often hang or crash crash labview.