VI has an error 2208

[vivante]

Hallo,

I have done some manteinance to an application compiled with LabVIEW 2012. That app has an installer, so my users can upgrade it easily. I usually install the application on the same machine where I develop with LabVIEW and after I try the installation procedure on a clean machine to see if issues arise. Today have seen that on the development PC, the executable runs fine. Instead on the clean machine, the following message appears after that the application has loaded the panel.

 

 

 

Have you seen this message in past? I have found some posts here: other users have found the same issues, with older versions of LabVIEW.

 

forums.ni.com/t5/LabVIEW/VI-has-an-error-of-type-2208-42308-302208/td-p/1540496

 

I have upgraded the DAQmx drivers on the clean machine , but the issue remains.

 

Any idea?

[Mike Le]

Bumping this thread because I'm running into the same problem a year later, with the same LabVIEW version.

 

I suspect it's related to dynamically loading classes in an exe, which is functionality I tried to add in just before the error started showing up.

 

The application runs fine in development and a build completes without errors. The error shows up as soon as the exe starts running.

 

I've tried to add a unique path in the exe for every class. This is a frustrating undertaking because there are probably a couple dozen classes being loaded dynamically, and the error doesn't tell me which class I'm forgetting (if any). So I'm trying to fix the problem by assigning unique paths for each class, but I can't tell where my mistake is because the error codes returned are opaque. And of course, the worst part is that I have to complete a build between every fix attempt, which sucks up massive amounts of time.

 

For all I know, I've successfully assigned unique dynamic paths for every class, but the exe is returning this error for some completely unrelated reason.

 

Anyone dealt with this before?

 

I was hoping to use some of the new class loading primitives in 2013 to do this without having to assign individual exe paths, but the entire 2013 development environment crashes when trying to load my project. So, hurray for that problem, too.

 

Mike

[ThomasGutzler]

Here comes another bump. Getting the 2208 error when running an executable on the same PC where it was built (and runs fine in LV). This is version 2016 32bit. Also getting the error when building on a different PC, same LV version.

The project has no libraries, only classes. All dll dependencies are there. I've tried clearing the compiled objects for both user and application builder. And I've installed .net framework 3.5 because that was a thing on the NI forum where a similar error was discussed. Did not help.

I tried building a debug version that waits for the debugger and attaching to it with LV but it just crashes LV before the application starts. Also tried hooking DETT into it but it shows nothing - probably because the application never actually starts running but just sits there with a broken run arrow.

Ideas?

[PiDi]

Put all your classes in libraries.

 

(I know it might contradict what others say about NOT putting classes in libraries, but it's worth a try. Also, I have all my classes in libraries and haven't seen this error for a long time).

[NRiver]

Another bump.

I ran into this problem today in LV2018. All classes were are in libraries and I was also not missing any drivers/ external dependencies. Clearing caches, mass compiling and addressing any issues I found there also did not help. 

The fix for me was to open it in LV2019 and save it back to LV2018. Hope this helps someone :)

[Jeff Hawkins]

And yet another bump....

Project runs fine in Dev.  Builds with no errors.  Then when it tries to run, can't find any of the lvlibp and spits out the error.  Used to run project in LabVIEW 2018 without issue.  But in LabVIEW 2020 - ongoing issue.  I got it to work for a moment, but then relocated files for GITHUB thing, and kaboom.  All classes have been migrated to LabVIEW 2020 and built appropriately.

[mattbaker.digital]

Check the executable log files stored in %TEMP%. These provide much more insight into what is broken vs. LabVIEW's terribly vague error information displayed in the UI. Example log attached.

I spent hours using the diagram disable structure on a large piece of software to slowly narrow down the library causing the issue. Building a debug version was of no use as the VI is broken on start-up. If I'd just looked at the logs it would have saved me so much time and frustration.

Turned out to be a broken PPL, but everything was fine in the IDE (a frequent bug with LabVIEW linking to old/broken references behind the scenes even after clearing the compiled object cache).

PTS-109_BrokenVILog_2023-05-05T090328.txt

Edited May 5, 2023 by mattbaker.digital

[Yair]

On 5/5/2023 at 5:58 PM, mattbaker.digital said:

Check the executable log files stored in %TEMP%. 

I don't see those and looking at your example, it doesn't seem familiar.

Which LV version is this?

Also, do you have any keys in the LabVIEW.ini file which perhaps enable these logs?

[Ajayvignesh]

I'm facing similar issue but with a different code 42308.  Thanks @mattbaker.digital I could figure out that some controls and protected VIs in a class was causing this trouble.  To add complexity, I have that class in a packed library.  For now it got fixed when I made all of those class scope to public.  Not an ideal solution to put all of them in public, but considering the project timeline to release, this is best to go ahead instead of dealing with this forever.

Regards,
Ajay.