now I found a funny problem with one of my LV2011SP1 executables:
When I create a new executable the executable refuses to run with an "There's an error. You need the development environment to investigate that" message.
Ok, so I turn on debugging in the executable and create a new executable. Now: the executable runs without any problems.
With debugging disabled it gives an error, with debugging enabled there's no error???
Ok, having some experience I removed all conditional disable structures in the code (some part of the code is only called with "Runtime Engine==TRUE"). Even that doesn't change that weird behaviour: Program runs fine in development environment and as executable with debugging enabled, but not as executable with debugging disabled...
Does anyone has similar experiences?
And no, I don't mind to post the full project. It's rather large and contains a lot of company internal information...
Solved! Go to Solution.
What happens if you disable debugging, but set all of the VIs to have their block diagrams included?
It could be due to a build optimization that gets suppressed when you enable debugging.
A good candidate is something private that unexpectedly gets attempted accessed publically after the build. For instance a poly VI in an LVLIB, where the poly VI is public but its instances are private. The 'Remove unused polymorphic VI instances' option will then make the builder strip the public poly VI and replace that with the private instance VI, thus creating a broken VI in the executable.
If your executable accesses a source distribution (SD) dynamically, and your exe and SD shares a library, and you have the 'Remove unused members of project libraries' option set in the builder, you could end up with missing library methods at runtime. This is due to the fact that only one instance of the library can be in memory at a time, thus either the exe or the SD loads its version of the library which might be lacking some methods the other party needs at some point.
Have you verified that all of your dynamically called VIs are always included in the build. We just had the same issue and it turned out to be missing dynamically called VIs. The other thing to check is if you use any other external DLL or DotNet. If it is missing anything like that you get this wonderfully descriptive error message.
I'm sure, that
- this executable doesn't use dynamically loaded VIs
- I'm not using LVLIB files of my own (maybe there are some in LabVIEW built in functions?)
- I'm not using any DLL or DotNet call of my own in this executable
It's a program to analyze measurement files from our teststands. So it uses my codebase regarding file formatting and channel settings management - the same functions (VIs) I'm using in teststand executables (to be clear about that: no, not TESTSTAND, but LabVIEW executables compiled for our teststands).
I will check the hint on disabling debugging, but including block diagram in the exe when I'm back in office next week...
Also check your options for disconnecting typedefs and unused polymorphic VIs.
I have had this issue before when I couldn't remove a block diagram. I believe I had used an Express VI for something and It required me not to remove the block diagram. I quick converted the express Vi to a normal VI and the problem went away.
When I turned on debugging to see what was going on, all the block diagrams are included, so the problem was fixed. I was fortunate that I had only made a couple of mods and was able to track down the issue pretty quickly.
thanks for suggestions.
It helped to check the option "remove type definitions" (additionally to default checks of removing unused polymorphic VIs and LVLib parts). Now the executable runs also without enabling debugging...