LabVIEW
When does LabVIEW release a .dll file after Call Library Function call?
What do you mean under "releases the .dll"?
Its quite easy to check. Just prepare code like this:
Then start dbgview and see when attach / detach happened.
You will see, that Process Attach called when VI (where this dll was used) is opened. Detach called when Front Panel closed. The same with reference: when open VI by reference, then Attach Process called, and when reference closed, then Detach happened.
Andrey.
Wiebe@CARYA wrote:
"epsilon-delta" <x@no.email> wrote in message
news:1234975210354-855675@exchange.ni.com...
> I have a VI that utilizes a Call Library Function node that calls a .dll
file. I would like to know when LabVIEW releases the .dll file.
Doe it occur when the VI is closed or when LabVIEW is closed?
It is released when all instances of the dll are released. So, when there
are no more VI's with the dll in memory.
> Is there anyway that LabVIEW can force the .dll to close. Here I
guess close means to remove the .dll from memory?
Dynamically (with VI server) calling the VI containing the dll would gain
some control over the dll. You can also make use of window api's to load and
release the dll, but it is much more difficult, since you would need to make
a way to call the functions by there pointers.
Regards,
Wiebe.
Using Dynamic VIs to wrap Call Library Nodes is a good solution for this.
Another solution would be to use the new feature since about 8.5 to specify a path to the Call Library Node. The DLL will be loaded on first call and remain loaded until you pass in a different DLL path. You can pass in an empty path to cause the DLL to be unloaded. However one single Call Library Node still holding onto the DLL will of course prevent it to be unloaded.
Rolf Kalbermatter
@dacad wrote:
The dll (from Tescom) is very picky and will not go away unless specifically told to do so or the link is severd by closing LabView entirely.
From what you described there is nothing special to this DLL in terms of not wanting to unload. This is standard Windows policy for all DLLs. As soon as an application loads a DLL, either explicitedly through a call of LoadLibrary(), which every Call Library Node does once for the affected DLL, or by implicit linking to a DLL by either another DLL or the process executable, that DLL gets mapped into the process space and its refcount is incremented. If the DLL is already loaded only the refcount is incremented.
When the module which implicitedly caused the DLL to be linked to is unloaded, or when FreeLibrary() is called, which the Call LibraryNode does whenever the VI that contains the CLN is unloaded, or when you pass a different name (including an empty path) to the path input, then the refcount is decremented and if it reaches 0 the DLL is unloaded from the process space.
If the Call Library Node is not executing because of an "error in" condition it won't do anything in terms of affecting the refcount of the referenced library either.
There are some exceptions during process termination, where the whole refcounting is more or less skipped since the entire process goes away anyways and also to prevent some nasty race conditions that Windows would otherwise run into during unloading of the various modules. But this is all Windows kernel interna and only a few people like Mark Russinovich understand enough about those issues to make a really educated comment about what happens during process termination in respect of DLL unloading.
