If you’re like me, you probably call VIs asynchronously all the time.  Like me, you’ve probably also been doing it wrong for years.  If you’re doing it like this…

…stop doing that.  For some reason (which I assume is a bug deep in the guts of LabVIEW) when you use a strictly typed VI reference to call VIs asynchronously like this, LabVIEW fails to release the VI reference…sometimes.  It’s a terrible bug because 99% of the time it works just fine, but every once in a while all of your libraries will stay locked after your code is done executing and you’ll be scratching your head trying to figure out why.  Instead, do it like this:

Removing the strictly typed VI reference fixes the issue and LabVIEW always releases references correctly.  Interestingly, the Actor Framework made this exact mistake up until a recent version which removed the strictly typed VI reference, as shown here.  I suspect this is the reason why I’ve had many Actor Framework based projects inexplicably refuse to unlock libraries in the past.  A comment in the Actor Framework code suggests that the strictly typed VI reference was removed for an RT bug, but I’m certain the bug occurs on Windows as well.  Also, the Actor Framework still uses strictly typed VI references for “Time-Delayed Send Message.vi”, which is (anecdotally) where I’ve seen this issue show up most often.  Maybe there’s a good reason why the time delayed send message VI was left this way, but I don’t know what that reason might be.  If Stephen Mercer or anyone else can explain this (and happen to be reading this blog post) please comment below!