how to unload DLL

[jyou]

Hello,

I am using LV 8.2 to call a DLL but I am facing a unload DLL problem:  the result can not be cleared from the memory even after I closed the VI.  Only way to unload the DLL is to shutdown the LV.

I was told to using VI server to call a subVI which deals with the DLL.  But for our application, using VI server seems not practical.  Is VI server the only way to solve this problem?  Anyone has an idea about this?  Thank you in advance.

---Julia

[GregR]

If you unload all VIs that call the DLL, then the DLL should unload. If it does not, either VI did not really unload or the DLL itself may be doing something to remain in memory. When DLLs start their own threads, it can be quite difficult to correctly stop those threads on Windows. Normally the first signal a DLL gets that it is being unloaded is the process detach call from the system. The problem is you cannot stop other threads from this call because of OS resources but you must make sure all your threads are done before this call returns. Many DLLs resort to making sure they never unload to avoid these issues.

[Wiebe@CARYA]

The obvious way to fix this is to fix the dll, or call it correctly so it doesn't create a leak.


Why wouldn't VI server be practical?


Another way to fix this is to use LoadLibrary (and FreeLibrary) and GetProcAddress and call function pointer with a wrapper...


Regards,


Wiebe.

[jyou]

Hello Wiebe,

Thanks for responding my question.  ...... The DLL was given by vendor.  In order to fix it, I need to get all their source code related to this DLL.  I am not sure I can do that or not.

"LoadLibrary (and FreeLibrary) and GetProcAddress " are used in C/C++, or CIN, right? 

I thought I have to use two mechines (IP/TCP) for VI server application.  Just find out it may be locally controlled.  I will give a try.

--julia

PS:  Sorry for the duplicated post.  I didn't know how to delete the other one.  

[Wiebe@CARYA]

"LoadLibrary (and FreeLibrary) and GetProcAddress " are used in C/C++, or CIN, right? 


These are actually simple dll's API's. You can use them in C/C++ or CIN (CIN's are obsolete), but also in LabVIEW. Only problem is that you can't call a pointer to a function in native LabVIEW. Check out Dynamic DLL.zip in the last message of this thread:


http://forums.ni.com/ni/board/message?board.id=170&message.id=39381&view=by_date_ascending&page=1



"I thought I have to use two mechines (IP/TCP) for VI server application. Just find out it may be locally controlled. I will give a try."


This won't solve the leak. The leak will still be there, but on another machine.



"PS: Sorry for the duplicated post.; I didn't know how to delete the other one."


That's OK. But if you can't delete it, at least edit it so it says "Sorry, duplicate post". If you don't, people might spend time answering questions that are already answered.


Regards,


Wiebe.

[jyou]

Wiebe,

"Only problem is that you can't call a pointer to a function in native LabVIEW." ... This will be a problem for me.  There are pointers in my dll call function.

I load the zip file "from http://forums.ni.com/ni/board/message?board.id=170&message.id=39381&view=by_date_ascending&page=1" 

Using user32.dll, I receive error message while calling store address sub-vi (call calldlldll.dll).  Using LVlibrary.dll gives error earlier.  ......... regardless, thanks alot for the expample.

--Julia

[Wiebe@CARYA]

Passing pointers as parameters is no problem (unless you have pointers inside structures, then you have to improvise). What I am refering to is calling a pointer to a function. For instance, you don't have a name like "MessageBoxA" but a pointer to it, like "0x325563". The calldlldll.dll resolves this problem. As I recall, the first parameter is the pointer, then there are all the normal parameters. But I might be wrong, it was a long time ago.


The calldlldll.dll will fail if the number of parameters is incorrect. Can you post the code that causes a problem with user32.dll?


Regards,


Wiebe.

[TreyB_NI]

Julia,

Take a look at this KB and see if it is useful.  It uses a trick to unload a DLL by calling the same call library function node a second time with an invalid path.

http://digital.ni.com/public.nsf/websearch/77594203D78D12278625729100758BE5?OpenDocument

[jyou]

Hello, Trey,

I have seen the same suggestion from LV 8.2 help file.  It did not work.  I tried with the example in this link, it doesn't work either.  .....  Running into error:  Error 7 ....  "empty path constant or null path constant " actually cause the error.  Another word, LV doesn't like the empty path constant, at leave the version 8.2.1 I am using won't take it.

Question, did anyone you know tryed the sample and executed without error?

Thanks!

---Julia

[jyou]

Trey B,

This works!!!!!!!!!!!!!!!! 

Thanks for sure.

Please ignore my last post.

--Julia