.vi loaded with errors on the target and was closed

[gsussman]

Some more information on this issue. I have a  large RT project (~4300 VIs , 120+ classes) that has been giving us fits on deployment.

A never ending string of ".vi loaded with errors blah blah blah" and LV crashes. Up till now it has taken between 15 and 25 minutes along with multiple object cache clears, LV restarts, and RT system reboots to obtain a successful deployment. It feels more like building FPGA code than trying to run on an RT system.

I have stumbled onto what appears to be a workable method to get the RT system to deploy. 

What we have found to work:

1) Load the RT project

2) Clear the compiled object cache

3) Attempt to deploy (for us this leads to a LV crash 100% of the time)

4) In the LV crash window, view the contents of the crash report, specifically the lvlog.txt file

Scroll to the bottom of the window and you should see something similar to the following:

---

---

<DEBUG_OUTPUT>
12/16/2016 11:24:14.129 AM
Crash 0x00000000: Crash caught by NIER
File Unknown(0) : Crash 0x00000000: Crash caught by NIER
minidump id: c3b9a253-1306-43c5-ace3-886eb861081d
ExceptionCode: 0xC0000005

</DEBUG_OUTPUT>
0x100011AB - nierInterface <unknown> + 0
0x10005E96 - nierInterface <unknown> + 0
0x10006538 - nierInterface <unknown> + 0
0x10001101 - nierInterface <unknown> + 0
0x10002109 - nierInterface <unknown> + 0
0x00692A35 - LabVIEW <unknown> + 0
0x01E43011 - LabVIEW <unknown> + 0
0x01E5647D - LabVIEW <unknown> + 0
0x755062FA - USER32 <unknown> + 0
0x75506D3A - USER32 <unknown> + 0
0x755077D3 - USER32 <unknown> + 0
0x7550789A - USER32 <unknown> + 0
0x01ED030F - LabVIEW <unknown> + 0
0x01ED0493 - LabVIEW <unknown> + 0
0x01ED0667 - LabVIEW <unknown> + 0
0x08C41AD6 - QtManager452_2015 <unknown> + 0
0x670E7251 - NIQtCore_2015 <unknown> + 0
0x00067B2A - <unknown> <unknown> + 0
0x00000000 - <unknown> <unknown> + 0
*** Dumping Bread Crumb Stack ***
*** LabVIEW Base Address: 0x00400000 ***
#** compile: "C:\<some path to your code>\<some random VI name>"
*** End Dump ***

5) Reopen your RT project and open the VI identified on the highlighted line first. Leave the VI open

6) Open your main deployment VI and attempt to deploy

In about 50% of the cases the project will deploy correctly, the other 50% will result in another crash and another error log. Repeat Step 4, until you get a successful deployment.

Using this method I can typically get a deployment to work in 1 or 2 LV restarts.

I can't guarantee this will work with your applications, but it is at least something more to try.

[MGiacomet]

Cop out!

>>"... we need code that demonstrates these bugs..."

No need for code samples, since by the variety of conditions in these many posts indicate, it has NOTHING to do with customer code. The code you need you have: it's LabVIEW!

Right now I'm in a situation that out of nowhere, it starts acting up. I then make an innocuous change in a VI, click on Save All, and sometimes during deployment I'm prompted to save unrelated VIs!!! Reason? "VI recompiled"... Why just now?! When these saves during deployment happen, then the problem goes away.

If NI cared, NI would at least start putting meaningful error descriptions. "vi loaded with errors" is useless! What errors??? Meaningful indication is the only way this will ever get resolved.

And WOW! This thread is EIGHT years old. Has NI done anything? Oh, yeah, spent time creating new fancy NextGen...

[Olivier_L]

I've got the same issue, since I'm working with LabVIEW 2017, classes, and RT targets.

Last week, I had this issue when I changed a typedef included in another typedef.

Luckily, I realized when I saved it that something didn't get as usual (I don't know how, something about the way the front panels are refreshed at save), then, thanks to this post, I realized that there were effectiveley something weird with my typedef changing, but I was unable to find somehing changed on it, and no way to update it manually.

If I remember well, I removed the Typedef I changed in the calling Typedef and included it again. probably had some popup saying to revert changes, several times, but I succeded to have it downloaded right.

Today, I just added some items into a typedef ring, not included in any other typedef.

Then, trying to run it on my RT target (where the same project was already running as an rtexe, without the ring updated), it showed issue deploying the VI (a class method containing a subVis containing the updated ring).

Also, a lot of VIs are seen as already deployed, even if I stop executing the rtexe at startup and restart the RT target hoping to deploy from a clean environment, because I expect that typedef in memory on Rt target is somewhere close to the issue.

Nothing changed.

I also tried to click "open typedef" from all instances of it on subVIs, and some of them was saying that typedef changed and asked me to revert. Then, saved the class containing the method, and deploy again without success.

btw, If I found quite understandable the revert popup when I've seen it in the past, since I'm working with classes, I feel it nonsense, and poping everytime without reason. There is something to work with Class saving and typedef cash to propagate changes when done.

As far as i'm going to add a lot of items to this Ring as I develop, I would like to be able to run my code each time, and not losing a complete day trying to make it work at each modification.

Maybe something that could help understanding the issue, I have a main VI, wich is the method of a class (using Messenger Library from JDPowell, and its actor class). This main lauches several other actor processes, and I develop all those classes on a project on my computer.

Then, I use another LV project where I declared my RT target and declared only the Main class on it (all other classes are in dependencies). Could this explain something with the updating process of typedef in dependencies?

[Olivier_L]

I just succeeded to deploy my Vis again.

I'm not sure of what I've done, but I guess I closed my project, open only the class with the method not succeeding to deploy.

Open the method and I did a CTRL-Shift-Run (wih no hope as I already did a lot of mass compile before).

Then the VI was marked as changed so saved it.

And I could finally deploy my main VI with success

[F1Nick]

I thought I'd post this here as it might help someone that's tearing their hair out like I was!

This became a problem for me last week which I now think was caused by the most recent update to LabVIEW 2017 (early June?). In the end I was able to fix this by clearing the compiled object cache, as described here;

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8ejSAC