VI refnum reference counting issues

[TurboPhil]

Questions:

Are there any tricks to help identify why a given VI is not fully able to leave memory? Is there a way to access the current refcount of a VI, or otherwise identify why a reference is still held open? Is there any way to *force* all references to a given VI to close?

Background:

We have a built executable that loads and runs *.vi files (that were not built into the exe itself). We are trying to support dynamic reload of the external VIs from disk. We can get *some* cases to work, but there are some situations where the VI never actually leaves memory (we even explicitly call the "All VIs in Memory" application property, and can see that the VI is never leaving memory). Suspect the problem is that somehow the RTE is incrementing the refcount of the VI. 

The VIs that we are loading at runtime are themselves pretty trivial, but some of the things we are doing *with* them is nontrivial. There are a lot of VI server calls where we are finding controls on the FP and getting/setting properties. We are attempting to limit the number of references opened to the VI itself to be exactly 1, but I suspect there are some VI server calls that we are doing that are implicitly incrementing the refcount.

Has anybody else run into this problem and come up with novel solutions? Are there any tools/tricks we can learn from? (Or even anything that *should* be obvious that I'm just overlooking?). Ideally, I'd like to have a way to say "force this VI to completely leave memory, so I can reload it from disk." If only the "Revert VI" method were available in runtime....

[Kyle97330]

Did you try putting a Request Deallocation node on all VIs you want out of memory?

[TurboPhil]

---

@Kyle97330 wrote:

Did you try putting a Request Deallocation node on all VIs you want out of memory?

---

Thanks for the suggestion, @Kyle97330. I suppose I could give that a shot, but I don't think that's what the "request deallocation" primitive is really for. But I'll see what happens...

[TurboPhil]

Yup. No dice on "request deallocation" primitive. Still have situations where the RTE won't completely unload VI from memory, despite best efforts to ensure that it is stopped, its FP is closed, and all references to it have been closed.

[paul_cardinale]

Are you sure that those VIs that don't unload weren't already in memory before they were dynamically loaded?

Can you check the execution state of the VIs that won't unload?

[paul_cardinale]

Are you doing anything with the clipboard?

If there's any LV code in the clipboard, LabVIEW won't unload any of that code's dependencies.

[tst]

---

@TurboPhil wrote:

Has anybody else run into this problem and come up with novel solutions?

---

Not specifically, but here are some quick thoughts:

1. Are there classes involved? AFAIK, they still don't unload until the end.
2. Did you try looking at the All VIs in memory property and then maybe looking at the Callers property of your specific VIs? I doubt it would help, but it might be worth a try?
3. Did you try the execution trace toolkit? I haven't used it recently, so I don't have any specific suggestions, but it might help. At the very least, you could add your own logs and see if you hit the relevant points.

[Neil.Pate]

Any code using .net classes? I have had something similar to this when using the .net Timers class and had to use a workaround to get everything unloaded properly.

[Ben]

Are the suspect VIs possibly opening a reference to themselves?

Ben

[wiebe@CARYA]

Is the front panel still open or hidden? Both will keep the VI in memory, also when it's open in a SubPanel (running or not).

I think we'd need a MWE...