LabVIEW
Fully release buffers acquired by an external DLL
I fully agree with Felix. It may be more aparent when used in LabVIEW but it is either a problem with the DLL doing STUPID things and not properly clearing up on the close() function or in how you call that DLL and don't understand how it's supposed to be used.
If it is something in the DLL, there is no way to solve that in LabVIEW. You could of course use the possibility to load and unload the DLL dynamically (though you would have to do it explicitedly with LoadLibrary() and FreeLibrary() since the dynamic option by providing a path name to the Call Library Node doesn't work in the way that would be needed to do this) but most likely this will not help, unless they included some extra clean up in the PROCESS_DEATTACH call of the DLLMain() routine.
More likely the already allocated resources will stay allocated as Windows only does resource cleanup on process exit, which of course an executable will do if you close it, but LabVIEW as development environment only unloads the VIs and stays in memory if not shutdown explicitedly so the automatic Windows resource cleanup is not triggered even if the DLL itself is unloaded.
So tell those driver manufacturers that not having problems in other environments is not any guarantee that they are doing things right but their defense only proofs that they really do not understand a lot about the problem and probably should have hired someone to write that driver who understands how it should be done.
DLLs doing anything else but initializing global state on load, and freeing any allocated resources on unload are basically broken. And Microsoft even goes so far as to say that you should never even attempt to release OS resources and especially unload dependant libraries in PROCESS_DEATTACH, UNLESS DllMain was called by an explicit call to FreeLibrary() which is indicated by a NULL value passed in through the "lpReserved" parameter of DllMain().
The reason is that while unloading a process and calling the DllMain() function of all the dependant libraries, Windows holds a global lock to many resources that could end up in a deadlock situation when calling functions like FreeLibrary() and other resource unloading functions during that.
Also normally only delay loaded DLLs are loaded at the first call to a function in it and that is normally a feature of the import library that comes with the DLL. However delay loaded DLLs are never unloaded once they were loaded until the module having loaded them unloads itself, and also only if no other module in the current process has still a reference to that library open. By default, import libraries will cause to load the DLL at the time the module referencing them is loaded.
So a scheme that relies on explicit LoadLibrary() and FreeLibrary() calls between calls to the library is not really incompatible with LabVIEW but simply requires the same procedure as it does when calling that DLL in other enviroments where you have to call LoadLibrary() and FreeLibrary() also explicitedly in your code. But such DLLs are really a monster to deal with especially during applicaton development and I would generally consider them broken.
If a library needs at mutiple times explicit initialization, and/or deinitialization putting that into the PROCESS_ATTACH is completely wrong. Instead the library should export explicit initialize() and uninitialize() functions for an application to call. PROCESS_ATTACH should only handle global state initialization, and PROCESS_DEATTACH can be used to clean up internal resources but should never call FreeLibrary() or similar functions when the lpReserved parameter is not NULL. Both PROCESS_ATTACH and PROCESS_DEATTACH should do NOTHING that is required to execute to make the DLL run between multiple uses.
