How to restore corrupt vi.lib\ActorFramework?

[OneOfTheDans]

I corrupted my Actor Framework source code, and can't fix it so far. When I open Actor Framework.lvlib in a new project, it has bad dependencies. The dependencies are to an Actor Framework PPL that I tried building recently. The corruption happened when I accidentally did Save All after building the PPL.

I tried copying over a known-clean copy of .\vi.lib\ActorFramework and .\resource\AFDebug from a different machine (same OS: Win7, same LV: 2017SP1).

I tried Clear Compile Object Cache.

Mass Compile of .\vi.lib\ActorFramework is clean.

The bad dependency is Message Enqueuer.lvclass. It's allegedly referenced by Actor Framework.lvlib:Actor.lvclass:Actor.vi, which has a white run arrow. If I Ctrl + Click the run arrow (which forces a re-compile of that VI?), LabVIEW immediately crashes.

Anyone have an idea why this is happening? Or more importantly, how to fix it?

[wrkcrw00]

I did this same thing with LV2017SP1. After creating the PPL, or trying to at least. AF was effectively broken and after trying everything including replacing vi.lib code, the only fix I found was to wipe LV and reinstall fresh. There were some bugs in LV2017 related to PPLs and AF that cause this. I don't know the details, but it's there. 

[OneOfTheDans]

Thanks for your input, at least I know now I'm (maybe) not crazy. Did you open a support request with NI? And were you ever able to get AF into a PPL on LV2017? Or should I just give up now?

[wrkcrw00]

I never was able to create a LV2017 PPL of AF. I believe others have been successful by copying the AF folder from vi.lib from LV2016 and putting it into their LV2017 vi.lib. I went to LV2018 instead and we have been able to create a PPL in 2018.

[p4keal]

I don't have expirience with PPL, but AF library crashs sometimes even without them... I use still LV2014SP1. Typicaly it happens if two or more AF projects are open. I created a GIT repository in AF folder and one intial commit. So if AF crashs i just revert all changes. Normaly it works again.

[OneOfTheDans · Accepted solution]

The root problem is the LabVIEW environment has some secret memory of dependency paths. The secret memory is separate from the source VIs, and not included in “Clear compiled object cache”.

My original issue was that the LabVIEW environment remembered bad dependency paths even after restoring my corrupt AF with known-clean source VIs. When I tried “Replace with” or manually compiling, LabVIEW crashed.

I fixed the problem by placing the files in my home directory where the secret memory expected them. That stopped LabVIEW from crashing and allowed me to “Replace with” the correct vi.lib location, which fixed the secret memory. Then I restored my vi.lib AF one more time with the known-clean version, and the LabVIEW environment was finally happy again.