Bug: Labview 8.5 consistently crashes on loading this vi

[GregR]

I finally had a chance to look into this and I can tell you that the issue was previously reported and fixed. I can't say exactly when that fix will be available, but it will be in the next version that is made available to customers.

[Anthony_de_Vries]

Hi Greg,

Thanks for the update.   I wonder.. will this fix be free of charge?   My boss decided that we didn't need to keep our service contract...  

Another question, which might be related to this issue.  After this crash, I haven't been able to build my application into a stand-alone application anymore.   It does built an executable, but when I try to run it, I get the error message: "vi is not executable, full development version of Labview is required to fix the errors"

I can't find any problems with the vi...   it runs fine as a vi on the development machine.  Just not as an executables.    Didn't have problems before with building executables...    Could this be related?  If so, is there a known fix?    

(attached the non-running exe)

[GregR]

It is possible that the problem running the built app is related to the typedef issue. One thing you could try is to force an update on all the instances of the type definition. You could add a control to the cluster in the type definition and allow that change to propagate to all the instances, then remove that control and propagate the change again. This should correct any minor differences in all the instances and might fix your build problem.

Hope that helps.

[Anthony_de_Vries]

Thanks for the suggestion Greg.  I forced an upgrade on the typedef's.   I did solve a few issues.  There were a couple of sub-vi's that would also crash when opening in the editor.   That's now solved.  Everything seems to work as it should...

Except for the application builder.   I still have the same problem.   The builder builds the exe without any errors.  But when I then try to run it, the thing is broken.  (broken run icon)   I can't even try to debug, because it doesn't start in the first place...  

I'm running out of ideas how to fix this...

[Anthony_de_Vries]

Cute...  to try to get the thing running, I'm trying options like including not removing unused polymorphic instances, and not removing unused members of project libraries.

Had to solve a few minor issues to get it to build the application, but that was easily fixed.  (All non-related things really...)

Not that it helped...  Now, when I try to run the application, I this dialog box:

I guess NI think they need to repeat important messages to us simple users...    
But really...   I DID understand after the third time! 

Message Edited by Anthony de Vries on 01-16-2008 12:09 PM

Message Edited by Anthony de Vries on 01-16-2008 12:10 PM

[DFGray]

This sort of error is typically caused by a piece of missing code, usually a driver.  I have seen this kind of error when making an application and moving to another computer which does not have all the drivers installed (e.g. NI-DAQ).  But, anything which can break a working VI will cause it.  Are you disconnecting typedefs when you build?  If not, try it.  If so, try not doing it.  Normally, when building an EXE, you would disconnect typedefs to reduce disk footprint and load time.  Are you removing front panels?  Some front panels need to stay.  If you use VI server calls to set/get front panel values or you have an event structure, you cannot remove the front panel.

A possible debugging technique, if nothing else works.  Write a shell VI that simply calls your main VI.  Change your build so that the shell VI is the EXE and everything else goes into an LLB.  Do not remove front panels or block diagrams.  When the build finishes, open your main VI from the LLB to check for problems.

Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.  Good luck.

[GregR]

It looks like your broken app has to do with classes that are in libraries. A class contained in a library built into an application will sometimes work and sometimes fail depending on an ordering used during the build that you have no control over. In your case only the PennyMotor class is causing the problem even though you have other classes in libraries. This has also been fixed but it will not be available until the next full release.

There are a couple of things you can try. It may avoid the problem if you turn off the "Modify project library file after removing unused members" option in the Additional Exclusions settings for your build. If that doesn't work, you can separate the library and class.

One more note on the slightly redundant error message. The vast majority of the time it represents something that went wrong with the build. When we look at what to fix, we tend to choose the build problem that caused the dialog rather than the dialog. It is a stupid dialog but there are priorities.

Message Edited by GregR on 01-17-2008 08:52 AM

[Anthony_de_Vries]

It works!!!  

I had just finished Damien's suggestions.   Nothing worked, except the shell VI, with putting the rest in a LLB.   Then it worked fine.  (Except that I had that shell VI open as well...)    Seeing Greg's post, I guess that the LLB solved the library issue with the class. 

Now that I read that the library + classes is the problem, I remember that indeed, I have been 'cleaning up' my code, by putting things into libraries.  So  I pulled the classes out of the library,  (no big deal, as there wasn't much else in it)  and then compiled.

And then it worked like it should.  No problems anymore.

Thanks for all your help guys!