LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabVIEW crashes by using Call Library function node

Solved!
Go to solution

Hello Community,

I am using a x64 bit DLL with a x64 LV 17.
I am going to write some program for controlling some PCI card. My first application just uses the init and close function which are located in a DLL (a specific one extra for the card).
After I start the computer and run the program which I had written the call of the specified C function everything is ok and the hardware is initialised and closed successfully.
However, if I start a second run LV crashes right at the part where the INIT function will be called.
I unload the DLL at the end of the close function with an empty path constant.

Could this be a LabVIEW issue or is this a DLL problem. What do you think?
Is the memory (or memory handle of LV etc.) responsible for this behaviour?

 

Any advise would be appreciated

Thanks for your help!

 

Regards

D-Kid

0 Kudos
Message 1 of 4
(2,721 Views)
Solution
Accepted by topic author D-Kid

The unloading of DLLs doesn't work as you imagine. Each instance of a Call Library Node will maintain its own DLL handle and retrieve it by calling LoadLibrary() on the first call. So you need to call each individual Call Library Node instance with an empty path to make sure that the same amount of FreeLibrary() calls are done to finally unload the DLL. As long as there is one single Call Library Instance not having been called with an empty path after it was called with a valid DLL path, the DLL remains loaded.

 

That said if the DLL crashes when you attempt to initialize it again after all Init calls are matched with an according Close call, then the DLL is crappy!!

Rolf Kalbermatter
My Blog
Message 2 of 4
(2,694 Views)

Thanks for your fast reply!

I changed the code and for every "Call Libary Function Node" I add a for loop so that the last DLL path given to this "Call Library Function Node" is an empty one.
This solves the problem with the crash.

 

However, this is -- in my point of view -- a weird behaviour due to the fact, that a similiar project works, also without the empty path constant.
That means, I have another project which uses another card and another DLL but without the empty path constant used in the source code. My current project is an exact copy of this working one but it does not work.
Further, it looks to me that the use of for loops is just a helping thing. Do you may know another possiblity to unload a DLL or is this the only way to do it?

Regards

D-Kid

0 Kudos
Message 3 of 4
(2,687 Views)

@D-Kid wrote:

Thanks for your fast reply!

I changed the code and for every "Call Libary Function Node" I add a for loop so that the last DLL path given to this "Call Library Function Node" is an empty one.
This solves the problem with the crash.

 

However, this is -- in my point of view -- a weird behaviour due to the fact, that a similiar project works, also without the empty path constant.
That means, I have another project which uses another card and another DLL but without the empty path constant used in the source code. My current project is an exact copy of this working one but it does not work.
Further, it looks to me that the use of for loops is just a helping thing. Do you may know another possiblity to unload a DLL or is this the only way to do it?

Regards

D-Kid


That's pretty much proof that DLLs are unique and needs to be handled as such, don't you think? Your program needs to follow the rules the DLL has set up for how it's initialized, used and closed, and this is often quite different between DLLs. That's just one reason why DLLs are a PITA.

/Y

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
0 Kudos
Message 4 of 4
(2,671 Views)