The full development version of LabVIEW is required to fix the errors

[bmann2000]

I've been gradually developing  a large GOOP application, it's been in development since 2012.  We've never had problems with executables before, but now when we create a build, when you run the executable, the run arrow is broken and you get the message "The full development version of LabVIEW is required to fix the errors".  Searching the forums there are many people who experienced the same errror message but with many different solutions.

The same happens on any PC, I can create the build on another PC, same result.

I can go back through SVN revsions until I find the last copy of the project that will actually build, but I would then need to repeat all the coding done since.  Is there anything I can do to track down the problem?  I suspect it may be connected with incompatible cluster types or a bad link to a sub VI, but the application is so large, it's impossible to look through all the code.

Brian

[BowenM]

Since you have SVN, I would try going through your revisions and compiling.  Skip a couple months at a time and build until the error happens.  If you can track down the exact revision that broke your built version you can look at exactly what VIs you committed.

[Sam_Sharp]

This usually happens where the application tries to load something that isn't present (or in the wrong place) when it's trying to load some dependency - this could be a missing NI toolkit, some dynamically called VIs (?) or a DLL - something like that.

Have you tried using the desktop execution trace toolkit to debug the built application?

It's also possible that you have some sort of odd corruption in your project/VIs that's making them bad - you could try force re-compiling before the build (ctrl + shift + run arrow?).

Are you trying to run the executable on your development machine, or on another computer (e.g. without the LV development environment)

Oh - it might also happen if the runtime engine tries to load a bad VI - do you have any non-runnable VIs in your classes?

[bmann2000]

Hi Sam & Bowen,

Thanks for the ideas.

Execution trace toolkit does not return anything because the run arrow is broken on the executable.

I've tried remote deugging but I don't get a front panel appearing as described in the knowledge base article.  I've never used this feature before, the knowledge base aritcle is aimed at debugging on a remote machine but it does allow you to point at localhost.  The exe has a greyed out arrow and message about being under control but there is no front panel for me to right-click on as described in the article.

I've been back through SVN to locate the point where it starts building an exe with a broken run arrow, but all I see are some very basic edits to 3 VIs.

I'm building the executable and running it on the development machine, the target machine also has the full development environment installed, I get the same result building on both machines.

I've completed mass compile and resolved the bad vis, there was a few but not part of the code used in the exe.

I've put in so many days coding since the last build in svn that it's too painful and time comsuming to repeat all the work again.  Also, I'm worried that if I simply revert via svn and repeat coding again, I might later be faced with the broken arrow in a situation on a customer site, I'd rather find the cause and understand the fix.

The exe does call a number of dll files and being object orientated it has a number of dynamic dispatch VIs.  It also has a few asynchronous calls with the associated referece inputs.

Any more ideas on what I should try next?

[Sam_Sharp]

Are any of the VIs in your classes broken? LabVIEW will always include any class method VIs in the executable so if one of them is broken, then you'll have a broken VI in your build specification which might be causing the problem. Remove any broken VIs from the classes (even if they are not called in the executable) and try again.

You could also try clearing your compiled object cache (under tools -> advanced) before doing the build.

Have you tried removing/disabling parts of your code until you get a successful build/executable?

[bmann2000]

Hi Sam,

I'm assuming the mass compile of the complete project folder would highlight any broken VIs.  I tried clear cache, no difference.

Is it possible that one of the class libraries is expecting a VI that is no longer present in the project.

It all runs fine from source.  Should I be able to create a exe with diagram enabled that would allow some sort of debug.  The problem I have is that I don't have any information to act on.

Brian

[crossrulz]

If things are dynamically called, it is likely you are not including needed VIs in the build.  Search for anything dynamically called (usually have a Open VI Reference to load it) and add that code to the "Always Include" section of the executable build spec.

[bmann2000]

Hi Crossrulz,

I've cross referenced the build properties always included list with that pulled from an earlier SVN version that sucessfully builds an exe without the broken run arrow.  All items required are on the list.  I've also removed all items from the always included list, then added them again in the hope it may repair a corrupted link.

Is there anyway to make the executable produce an error specific to the broken run arrow?  The application is very large and has been in use and subject to incremental improvement since 2012.  It's not easy to isolate any particular part of the code, I can try a few case statements to disable some of the major processes in the code, but I fear that will only lead to a very lengthy trial and error exercise.

[JÞB]

OK you cleared the obj cashe - and recompiled everthing GOOD, you also looked through allways enclude - nothing found GOOD. Did you Clean the build before rebuilding?  Try that first! then: we get to the harder stuff.

Probably the quickest way to drill through the problem is to enable remote debugging on the broken exe then open a debugging session from a machine with the full dev enviornment.  that will allow you to use the error window to isolate the root cause fairly quickly.  NOTE: this may just ressult in a running exe  (Wildly suspicious of an unknown bug)

I'l also recommend running VIA on the vis that commited when things went bad.

Lastly, you could through up a "Test App" that is a simple use of the vis you most likely suspect and see if it deploys.  When you do find it its likely something farily obvious

[Alexander_Sobolev]

I would not pay attention to missing dynamic dependencies. Exe finds they are missing when main vi opens reference to them, when it is running.

Last time when I got the same were:

1) Remove use 8.x file layout in Advanced section of build settings.

It was buillding for a long time, then after adding some dependency it stopped working

Caution: If you are using dynamic dependencies inside exe, it might affect path

2) Additional exclusions settings.

At some point it helped to uncheck "Remove unused members of project libraries". It increased build time and exe size, but it helped. Then I isolated some interproject dependency into separate library and it helped to go back to check  "Remove unused .. libraries".

I usually do not disconnect type defs, but both choices can cause conflict

If you check "disconnect typedefs", it will not include ctl files into build and you will not find them when you load them dynamically. - but it will not lead to broken arrow.

If you uncheck it and vi is recompiled with typedefs, you might get typedefs mismatches for static dependencies from different builds.