Application broken after it stops - FileVersionInfo.vi likely cause.

[JohnG3k]

I have build an application that run fine in the development environment, and also runs fine as an application. I haven't yet implemented shutting down the front panel when it stops as it is sometimes handy to restart the application. However a curious thing happened the the most recent build... after the application stops the run arrow turns broken. It runs fine when launched if not open already, but then has a broken run arrow after running. Clicking on the run arrow gives this:

Regarding the suggestions here for error 2208, the appropriate runtime is installed, I have .NET 4.8 which is the newest recommended version, and I just recently upgraded to LV2023Q1. The other errors all seem to also be related to LVRT engine revisions.

Running the application debug utility, and then opening the Error list shows no VI's with errors.

I've only made two changes since the last build... 1) Finally updated LabVIEW from LV2020SP1 to LV2023Q1, 2) Updated a simple VI that now reads the revision of the application using FileVersionInfo.vi found in vi.lib/Platform/fileVersionInfo.llb.

Commenting out the sub-VI that calls FielVersionInfo and re-building the application give me an application that doesn't have a broken run arrow after is stops. But this sub-VI is not broken when the main VI is broken (when viewed using application debug). So I'm really puzzled about the cause and how to fix it (short of just not reading the rev number, but I need that feature).

Thanks,

John

[Kyle97330]

The built-in file version VI doesn't use .NET, it uses standard DLL calls to version.dll and kernel32.dll, so any .NET runtime troubleshooting you try shouldn't apply.

I would recommend switching to using .NET and see if that helps.  You should be able to get the equivalent data with a call to System.Diagnostics.FileVersionInfo.GetVersionInfo() .  We use that in our code and have had no issues in numerous different EXEs.

[JohnG3k]

Thanks for the suggestion Kyle97330. I've used that in the past too, and gave it a shot but unfortunately still had the same problem. I then removed the code entirely and still had the same problem, so it seems that this was a red herring... that previous test just happened to co-inside with another change in test conditions I didn't realize.

From further testing it seems that one of my processes is not shutting down correctly when executing as an application, so presumably it's VIs are still reserved for execution, causing the parent VI to broken since it can not access the required VIs.

Thanks,

John

[JohnG3k]

Issue turned out to be a broken class due to file path being too long (similar: https://forums.ni.com/t5/LabVIEW/Get-LV-Class-Default-Value-Error-1498/td-p/1129973), causing an error when launching an Actor... this in combination with not handling this error properly likely caused the launching Actor to hang and blocked access to required vis. Shortening the name of my exe file fixed the problem.