how to unload DLL

[jyou]

Trey B,

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

Thanks for sure.

Please ignore my last post.

--Julia

[jyou]

Wiebe,

Sorry for replying you late.

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

The code I used is your code.  Only thing I did was to link the DLL files from the right locations.  "Store Addr" has one inputs which is feed by the output of "Get addr".  THis input is used as hModule for the function StoreAddress in your calldlldll.dll .... I am an entry level for this subject.   Wish I can give more inputs besides getting answers from others 

[jyou]

Wiebe,

Sorry for replying you late.

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

The code I used is your code.  Only thing I did was to link the DLL files from the right locations.  "Store Addr" has one inputs which is feed by the output of "Get addr".  THis input is used as hModule for the function StoreAddress in your calldlldll.dll .... I am an entry level for this subject.   Wish I can give more inputs besides getting answers from others 

[jyou]

Yes, it works if I only execute the "load" (call DLL) first, then "unload" (give an empty string to the dll reference) .  If the "load" and "unload" is in the same VI and executed in sequence, it would crash if you run the VI again     It must be a leak somewhere.

----Julia

[TreyB_NI]

---

@jyou wrote:

Yes, it works if I only execute the "load" (call DLL) first, then "unload" (give an empty string to the dll reference) .  If the "load" and "unload" is in the same VI and executed in sequence, it would crash if you run the VI again     It must be a leak somewhere.

----Julia

---

So if you run the VI, which contains the load and unload work around in series, and then run the same VI again it crashes.  At what point does it crash?

If it is a memory leak, I would suggest contacting the DLL vendor. 

[jyou]

TreyB,

I have to go back one step.  With simple load, I run the VI without problem. then I provide empty path to the dll reference to the same VI and re-run the same VI as unload.  It has no problem.  I can repeat this load and unload many times. However, if I chose exit/close this VI, LV crashs. Cause by memory.cpp.  ............ With the same VI, if I load and unload DLL in series in the same run, LV crashes regardless I try to run the same VI or another VI/application.  Basicly the LV was "dead" after run the series of DLL call.

Do you think this Is DLL's problem ?   Thanks in advance

---Julia

[TreyB_NI]

Julia,

What is the specific error that you are getting?  Such as an error number, or a line number associated with the memory.cpp?

[jyou]

"What is the specific error that you are getting?"

The error is:

Fatal Internal Error: "memory.cpp", line 342

[TreyB_NI]

Memory.cpp errors with DLLs generally mean that the DLL is not allocating memory correctly, or that LabVIEW is not calling the DLL correctly.  This KB reviews some of the common causes of DLL crashes.

http://digital.ni.com/public.nsf/allkb/3B994675B17C654A86256FDD00754DD2?OpenDocument

DLL crashes don't always happen when you call the DLL.  Overwriting LabVIEW memory sometimes won't show symptoms until LabVIEW tries to access something that uses that memory.

Message Edited by Trey B on 06-07-2007 05:06 PM

[Scott_Jordan]

Trey,

The KB article to which you linked [http://digital.ni.com/public.nsf/websearch/77594203D78D12278625729100758BE5?OpenDocument] is very useful.  Unloading a .dll has been something I've wanted to do on occasion and previous versions of LV (pre-8.2) would not allow it.  So, this is a nice feature to finally have.  Vital, in some circumstances.

But here's a question.  The article states, "If an empty or invalid path is wired to a different node than the one that initially called your DLL it will not unload the DLL from memory."  It goes on to show a wrong way to do it: by placing two identical CLFs in a dataflow chain.  

But what if the naked CLF instances were replaced by the CLF inside a non-reentrant subVI?  Then it would be calling the same instance of the CLF.  Would that be kosher?  One can't always put code in a state machine or other loop structure as in the example.  See my subVI diagram below. 

 Any illumination would be very much appreciated.  Thanks!