Control reference is invalidated (Error 1055) only when running in built executable (LabVIEW 2012 Runtime Engine)

[Ryan_Chamberland]

I have an application that works normally when run in the LabVIEW 2012 development environment, but when run from a built executable, a reference to a tree control becomes invalidated after what seems to be a set amount of time, giving error 1055. I've disabled the subVI where this occurs then re-built, then it just occurs in another VI that uses the reference upstream. Tried Re-linking subVIs, uninstalled LabVIEW DSC module as someone suggested to another similar post, re-made the build spec from scratch, tried wiring up the tree control reference directly to the subVI's connector pane to be sure it's getting a valid reference, and still I get error 1055 when attempting to run.

I found a similar but slightly different post with no solution that might be useful for anyone attempting to look into this:

https://forums.ni.com/t5/LabVIEW/Control-reference-goes-invalid-in-built-applications-if-passed/td-p...

Any help would be appreciated

[billko]

My only guess is that one of the advanced build options doesn't like being set at its default value.

[Ryan_Chamberland]

Bill,

I should have added that I've tried building with combinations of enabled and disabled debugging, LabVIEW 8.x file layout, and SSE2 optimization to no avail.

[billko]

---

@Ryan_Chamberland wrote:

Bill,

I should have added that I've tried building with combinations of enabled and disabled debugging, LabVIEW 8.x file layout, and SSE2 optimization to no avail.

---

I kind of figured you would have covered those bases, but I had to make sure.  How about the disconnecting typedef's and stuff like that?

[Ryan_Chamberland · Accepted solution]

Welp, turns out it was because there was a file not in the proper location relative to the built application, and due to improper error handling, this manifested itself as an invalid object error. Let this be a lesson to anyone who sees something similar and is banging their head over it

[billko]

---

@Ryan_Chamberland wrote:

Welp, turns out it was because there was a file not in the proper location relative to the built application, and due to improper error handling, this manifested itself as an invalid object error. Let this be a lesson to anyone who sees something similar and is banging their head over it

---

Ouch.  I was too afraid to suggest this.