LabVIEW
Unload DLL freeze my application
I made an application with LabVIEW 64bits that use external DLL. I use this technique to load and unload the DLL from memory : http://digital.ni.com/public.nsf/allkb/77594203D78D12278625729100758BE5
When I unload the DLL from memory the application freeze.
If I don't use the Load Unload technique, my Application freeze when I close it and the Icon remain in the task bar.
It there any known issue about that for LabVIEW 64bits.
Anyone know a work around?
Thank you
@DanyAllard wrote:
I made an application with LabVIEW 64bits that use external DLL. I use this technique to load and unload the DLL from memory : http://digital.ni.com/public.nsf/allkb/77594203D78D12278625729100758BE5
When I unload the DLL from memory the application freeze.
If I don't use the Load Unload technique, my Application freeze when I close it and the Icon remain in the task bar.
It there any known issue about that for LabVIEW 64bits.
Anyone know a work around?
Yes I do. Fixing the DLL hang! 
Most likely your DLL tries to do BAD things in the "process deattach". Microsoft specifically says that there are several things one should NOT try to do in a DLL when it is unloaded. One of them is for instance trying to explicitedly unload other DLLs that the DLL loaded previously. There are quite a few other operations that Microsoft strongly suggests to never try to do while the DLL is unloaded.
Basically when unloading a DLL Windows holds one or more locks to various system resources and several API calls can also try to get such a lock and if you are unlucky they will deadlock. This is much less likely if the DLL is called from a simple single threaded executable (which is often all a DLL developer dares to test if he even tests anything ) but LabVIEW is highly multithreading and there is a good chance to hit such a deadlock if a DLL tries to do BAD things in "process deattach".
The only thing you can try to do, which is by no means a guarantee that it should work, is to put all Call Library Nodes to execute in the UI thread. That can sometimes lower the chance to run in a system deadlock situation, especially if the DLL is itself using COM components that use Apartement threading or an even more restrictive threading model, but it is a bad band aid at best. Fixing the DLL is the only real remedy.
Hello Rolf,
I tried both UI thread and Any Tread without success.
I have the source code of the DLL I call. Do you have some advice on what to do to fix this problem at the DLL side?
I will ask my C++ developer to look at it.
Thank you
Well, without seeing the DLL source all I can say is to look in the DllMain() function and in there specifically the PROCESS_DETACH case.
MSDN is very clear that one "must not" call LoadLibrary() and FreeLibrary() in PROCESS_ATTACH and _DETACH. That said it often works anyhow, but not always.
If you want to get more into dirty details of the NT loader/unloader you may find this series of blog posts interesting to read. But beware it is not suitable brain food if you are feeling tired or are annoyed about something. 
