Application works in Development environment but does not work in EXE

[D_mitriy]

Hello,

I have issues with my application - it works perfectly in the development environment, but does not work inside exe.

DQMH version: 6.0 (latest from VIPM).

LabVIEW version: 2018 64 bit.

What happens: 2 modules (always the same) just won't start when they are inside executable. 

Error text (similar for both affected modules): 

Error 1003 occurred at File IO.lvlib:Start Module.vi

Possible reason(s):

LabVIEW: (Hex 0x3EB) The VI is not executable. This error may occur because the VI is either broken or contains a subVI that LabVIEW cannot locate. Select File>>Open to open the VI and verify that you can run it.

Complete call chain:
File IO.lvlib:Start Module.vi
Tracker Main.lvlib:Main.vi
Tracker Main.lvlib:Main.vi.ACBRProxyCaller.10300003

Here "File IO" - affected module and "Tracker Main" is actually main module which is trying to run the broken one.

What I've already did:

• Checked that Start Module.vi is actually OK (and app works like a charm in the development environment).
• Modules validation via DQMH validation tool.
• "Clear compiled object cache" and then "Mass Compile".
• Build settings set accordingly to https://forums.ni.com/t5/DQMH-Consortium-Toolkits/my-DQMH-PPL-and-VILIB-PPL-best-practices/td-p/4155...
• Added an additional 1 second delay before launching every module - no luck.

Two more things:

If I try forcibly re-start the module which is failed to start, I will get an error

"Error 403681 occurred at File IO.lvlib:Module Not Running--error.vi:6400001

Possible reason(s):

File IO Module is not running."

Despite that fact that the module is not running, this should be a "clean" start. The same error I will get if will try to immediately (within a ~second range) re-start any module which was closed on purpose.

The same project and modules were OK inside exe with DQMH 5.0. Unfortunately, I didn't made a test build right after the upgrade and now there a quite large difference between 5.0 and 6.0-based code.

I would appreciate any advice.

[Taggart]

There is a VI Analyzer Test that checks to see if you are calling anything that doesn't work in the run-time engine. I suggest you run that an your module. It might turn up something.

[Cloedu72]

Hello D_mitry

I suspect you have one of the following problems:

- Controls on the front panel of the Main.vi with Private Access Scope. (all must be Public!)

- try with "disabled structure" in Main.vi to narrow down the problem. It will be for sure a Typedef with Private access scope

- if the PPL again uses new PPL, try to start without this code

- search for missing items in your main-project and the projects of your PPL's

I know this hard way very well! 

https://forums.ni.com/t5/DQMH-Consortium-Toolkits/my-DQMH-PPL-and-VILIB-PPL-best-practices/td-p/4155...

Show us a PrintScreen of your Dependencies, maybe I can see the problem.

[D_mitriy]

Hello Sam and Fridu,

Thanks a lot for your comments and suggestions!

Concerning the VI Analyzer: by some reason I can't find a way to analyze Runtime in my version of VI Analyzer Toolkit (2018). It's either don't exists in my version, or I overlooking something. Sam, could you please point me to exact test name?

Concerning other suggestions and measures: 

• Fortunately, I do not have any PPL's.
• I've implemented all measures suggested in the linked document (incl. access scope) + cleaned up every single error (even in the test files) in the Mass Compile. This helped to solve issue with 1 out of 2 affected modules. Second module still won't run with the same error.
• Reinstalled LabVIEW on the different computer in order to check any specific-computer related issues. (Un?)fortunately, there is no difference.

Next steps: will try to add more errors logging, every single Typedef will be moved to the library with the Public accesss scope.

Screenshot of the Dependencies (does not look suspicious to me):

Update:

Okay, that's getting more interseting. After I've moved all Typedefs from the "broken" module to the Publicly accesible place, software still runs in the development environment, but I can't compile it anymore (Fridu had right feeling that something wrong with Typedefs). New error while attempt to compile:

"LabVIEW cannot find a file that is a dependency of a Startup, Exported, or Always Included VI.

File Not Found: F:\Documents\Projects\path_to_the_old_obsolete_control_from_the_old_project_which_is_even_does_not_exists_on_that_computer_nor_in_the_project_or_it's_dependencies.ctl

The missing file might be referenced by one of the libraries included in the build or by the file - Startup.vi. To fix this issue:

- Open all Startup, Exported, or Always Included VIs, recompile them (CTRL+SHIFT Click the Run arrow) and save them to update their dependencies.

"

Interestingly, that all items are OK, Mass Compile is done and clean, no missing items in the project, in the development evnvironment everything works.

None of the controls that I've moved has anything similar with the mentioned old project control. But compilation fails 🙂

Now I'm making another whole project test with Analyzer toolkit. Let's see ifit shows something.

[Cloedu72]

Have you copied and renamed the project file? Then you need to create a new build specification.

Try to search your missing file with notepad++ in the lvproj and all lvlib files.

Claude

[D_mitriy]

Thank you, Fridu. I just made a little change to a build specification and that solved the build issue. By the way, no any single mention of that old typedef was found.

Concerning the main issue:

Nothing really serious been find in VI Analyzer tests results. By the way, meaningful "red" tests results were checked and fixed when necessary.

Also I've made a separate Startup.vi which only launches the "bad" module.

Findings so far:

"Start Module.vi", fails with error 1003, i.e. the very first vi, "Get Module Main VI Information.vi" always returns "Bad" status and never "Idle".

Probably that means that it just has no way to even try to launch module by some reason. Will continue investigation.

[Cloedu72]

You can try something that i dont recommend for PPL's. But for executables its ok:

[D_mitriy]

Thank you for suggestion! With just a bit different setup it worked!

(previously both tickmarks were selected on yellow, see below).

On the downside, is that I still do not really can find why that problem popped out of the blue. And there are no any warning or even hints from the compiler.

Thanks a lot once again for your kind help!

[Cloedu72]

I guess i have to open an additional thread for best practices ans lessens learned for applications! 😉

If you use the DQMH libraries as PPL you don't need to set this parameters. But the parameters for PPL's are extremly sensitive!

Glad it worked!

Claude

[D_mitriy]

That would be great! 

All the best,

Dmytro