Intermittent (and infrequent) "The VI is not executable. The full development version of LabVIEW is required to fix the errors" message

[AndyF]

Hi,

I have an intermittent and somewhat infrequent "The VI is not executable. The full development version of LabVIEW is required to fix the errors" message that appears on two separate systems running completely different executables and have completely different hardware specs.

Most of the time it works, but then now and then it doesn't. A restart usually fixes the issue.

Both exes are running on Win7 64bit machines, written in LV2014, and have LVRTE2014 SP1 f11 installed. LV2014 Development environment is installed on the PCs in question too.

I have updated the .net framework to the latest version to no effect.

Reading through as many similar topics on the forum as I can find most people seem to have an issue with the exe simply not working, rather than what I am seeing where it works most of the time and then falls over with this error message a couple of times a week, or less.

Reading through some posts, the one thing that is common is the presence of diagram disable structures and possibly classic string indicators.

Other than that, there is little or no similarity between the software versions other than the operating system and LabVIEW version. One application is rather complex and has a multitude of I/O, the other is rather simple but uses a vision system consisting of two cameras, one of which is USB3 and the other is firewire.

Can anyone shed some light on the matter?

Thanks

[sirwin]

Can you post any source code?

Does the VI in question show a broken run arrow in the development environment?

[AndyF]

I'll see if I can strip down the code as some of it is company sensitive.

The code runs fine in dev mode, and builds fine and runs as an exe fine for most of the time, just not all of the time.

Regards

[CoastalMaineBird]

When the message occurs, what is happening on the system?

(  )  Launching the app

(  )  Quitting the app

(  )  App has launched and been working, but now you're trying to ______

(  )  App has launched and been working, and then it crashes on its own.

[AndyF]

Hi Steve.

Thanks for taking the time to reply.

Typically it occurs when the app is launched. The PC could have been running for some time, or shortly after it's switched on.

The other cases are true:

It can happen when the app gets shut down and then restarted after a short period of time.

It can happen when the app gets shut down and then restarted after a long period of time.

To rule out other cases:

I've successfully shut down the app and restarted it immediately, mutliple times

I've successfully shut down the app and restarted it after a short or long period of time, multiple times.

I've successfully shut down the app, immediately loaded a separate app, closed that app and reloaded the orginal app multiple times.

It's somewhat random and I can't repeat it or predict when it will happen.

Best regards.

Andrew

[sirwin]

Is your app calling a library on start-up? If that library is shared with another application, it may still be locked by that other app. Sometimes some applications don't release libraries cleanly.

[CoastalMaineBird]

OK, all that is consistent with the idea that some piece (external DLL, LVLIBP or VI) is busy.

Can you list what pieces might be external?  Are you using LVAnalysis.dll, or LVInput.dll, or some other piece that would be dynamically loaded, rather than statically included in your EXE?

If it was truly missing, it wouldn't likely be missing "intermittently", unless it's located on a network volume.  Can you confirm that there are NO pieces residing on a networked drive?

if there ARE pieces on a network drive, ask yourself why that is.

Unfortunately, this is a symptom of LabVIEW's penchant for secrecy - rather than tell you what exactly is missing, it's just "something's wrong". Unhelpful, always.  Infuriating, at times.

[CoastalMaineBird]

I have updated the .net framework to the latest version to no effect.

Are you directly using .NET objects?

Are you running other programs on the machines?

Did it    A) run well for some time and then start occasionally misbehaving,

       or  B) misbehave occasionally since deployment?

if (A), what happened to the system at that time?  (New gizmo, Windows update, full moon...)

Is it only after a Windows REBOOT that it misbehaves?

Is your program set to autostart after Windows boot?

If so, could you stand to wait 10 seconds on startup before doing anything?

[550nm]

Are you 100% sure you've seen the problem the first time the app is run after a reboot?

I've seen applications not terminate correctly; some process lingers, tying-up a resource.  This kind of issue would not show up until _next_ time the application was run.  (...and would never happen on 1st run after reboot).

[AndyF]

Hi,

It shouldn't be calling up a library on startup, it does very little in the grand scheme of things. It loads two cameras, updates the GUI and waits for a user input.

I'll be adding some code once I've stripped out anything sensitive.