Application Broken with error 6208 on a particular PC

[johntrich1971]

---

@Fedor wrote:

Ben,

Thanks for quick reply. I have the source code. The number 6208 does not appear to be an error code, but an error type number, whatever it could mean. I do not think is is a custom error code either since exact same behavior was reported on the forum by others before.

I would like to re-iterate that the application runs fine from within the LabVIEW development environment in all versions of LabVIEW tested.The application compiles into executable.The executable runs fine in all versions of runtime engine but the 2019 SP1.

I do not have tools to identify the reason for this run-time engine behavior. I'm wondering if NI might have them in house.

---

Did you try searching the code as Ben suggested? There is no "Error Type Number" in LabVIEW other than the Error Code. 6208 is definitely in the Custom Error Code range. Are you using some third party drivers? If so perhaps you and the previous poster(s) are using these same third party drivers. If these drivers are not accessible then you would need to contact the driver manufacturer about the error.

[Fedor]

I was able to reproduce the problem with a simple example, using just Labview built-in Xcontrol and Actor Framework tools. 

The problem pops up when I include a reference to Xcontrol into class data. Please see attached code.

[Ben]

There is a part of my brain that says "XControls and Classes do not mix" but that may be dated.

Ben

[Fedor]

Thanks for looking into it Ben.

I would like to note that application with this mix of Actor Framework and Xcontrols has been working fine for the past  5-6 years through all the LabVIEW versions. It still works fine in 2019 SP1 IDE, but is broken when opened  in run-time engine with undocumented and untraceable error type. 

It might be possible to reproduce the problem without using LabVIEW classes if only I had all the time in world to try and figure it out. 

Most of the older posts with similar error behavior point to missing or outdated dlls. I wonder if NI own runtime engine developers could look into it.  

[Ben]

I can offer only a bit of a guess.

There was an issue going back to about 2017 where under some unknown condition, LV would loose track of Class constants. In LV 2017, LV would not be able to detect the issue until the class was actually used in running code. But if you chased down into "every crook and nanny" you would eventually find a class constant that appeared to be "grayed out". Replacing that instance of the constant fixed the problem.

Latter "someone in another private forum" figured out how to find those constants programmatically. That "work-around" was then integrated into latter versions of LV such that LV will now break when that grayed out class constant was detected to help us notice and fix the problem.

So...

Since it seems you have the source code, chase down the broken VIs looking for a funky class constant.

If that does not help you, maybe it will help others.

Doing what I can,

Ben

[Fedor]

Hi Ben,

I would like to re-iterate that the source code is not broken. Would you have a minute to take a look at the source code attached to this post and the resulting application, if you have LabVIEW 2019 SP1 installed?  The attached source code consist of a single class and a method. Storing a reference to a control in class data breaks compiled app in SP1, but not in earlier runtime engines.

[Ben]

In 372 days, yes.

Until then I am under restrictions.

Ben

[Fedor]

I tested the bug with March 2020 patch: LabVIEW 2019 SP1 f1 Patch.

The bug is still there:

How can I bring it to LabVIEW bug fixing team to have it addressed in the next patch? I know there's a list of known issues floating arround somewhere. How the issues become known to National Instruments? I've emailed it to our representative last year, was redirected and the issue killed I guess(?)

[E.Schneider]

We had the similar error in our application (type 4E7E8, LabVIEW 2017 64bit, Win10) when we enabled the setting "allow future versions of the labview runtime to run this application" in the build specification. Disabling solved the problem.

[Fedor]

I just tested the suggestion to disable "allow future versions ..." option in the build settings, but the resulting application remains broken. 

I also note that the only LabVIEW runtime engine version that have this bug is 2019 SP1. Every other version, including 2017, worked fine.