LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

dll spontaneous unloading

I am using third party dll in my project. The problem is that this dll spontaneously unloads and loads during program execution. This makes problems with calling functions. Sometimes functions return errors.
I use LabView classes with virtual inheritance in this project. This allows me to decide control interface (UART, SPI, GPIB ...) at run time. In other words I have parent class say called INTERFACE and a few classes (UATR, SPI, GPIB ...) inherited from INTERFACE. I use external dll in SPI class functions which are called dynamically at run time if I decide to use SPI interface. So there are no explicit dll functions calling in my code. This I think makes a problem with spontaneously loading and unloading the dll. Am I right? What do you think? If I am right I think I have to tell LabView not to unload this dll until program termination. Could somebody give me a clue how I can do this? Thank you.



0 Kudos
Message 1 of 4
(2,747 Views)

I've tried VI which calls dll function explicitly. Situation is the same. The next is a part of dll log file with my comments. They told me that process attached detached messages correspond to dll load unload. Is this normal that LV loads dll so many times? I've found in one topic of this forum that LV loads dll when a VI containing dll call is loaded. But in my case I can see a lot of "ATTACHED" massages at run time. There are also a few "DETACHED" messages at run time. Do you think this is normal LV behavior to unload dll at run time?

 
[25.06.2008] [15:31:23] PROCESS ATTACHED m_hwnd :: (1) 0x00000000
[25.06.2008] [15:31:24] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:31:24] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:31:25] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
LV project started
[25.06.2008] [15:31:46] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
Test VI loaded.
Starting Test VI...
[25.06.2008] [15:32:17] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:32:20] PROCESS ATTACHED m_hwnd :: (2) 0x00220378
[25.06.2008] [15:32:20] PROCESS ATTACHED m_hwnd :: (2) 0x00220378
[25.06.2008] [15:32:46] PROCESS DETACHED m_hwnd :: (3) 0x00220378
[25.06.2008] [15:33:18] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:33:30] PROCESS ATTACHED m_hwnd :: (2) 0x0030036E
[25.06.2008] [15:33:30] PROCESS ATTACHED m_hwnd :: (2) 0x0030036E
[25.06.2008] [15:33:30] PROCESS ATTACHED m_hwnd :: (2) 0x0030036E
[25.06.2008] [15:33:30] PROCESS ATTACHED m_hwnd :: (2) 0x0030036E
[25.06.2008] [15:34:23] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:36:15] PROCESS DETACHED m_hwnd :: (3) 0x0090039A
[25.06.2008] [15:37:00] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:37:12] PROCESS ATTACHED m_hwnd :: (2) 0x009B03EE
[25.06.2008] [15:37:12] PROCESS ATTACHED m_hwnd :: (2) 0x009B03EE
[25.06.2008] [15:37:12] PROCESS ATTACHED m_hwnd :: (2) 0x009B03EE
Test stoped.
[25.06.2008] [15:37:48] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:37:52] PROCESS DETACHED m_hwnd :: (3) 0x00000000
[25.06.2008] [15:37:52] PROCESS DETACHED m_hwnd :: (3) 0x00000000
[25.06.2008] [15:37:53] PROCESS DETACHED m_hwnd :: (3) 0x00000000
Test VI unloaded.
[25.06.2008] [15:38:39] PROCESS DETACHED m_hwnd :: (0) 0x00000000
LV project unloaded.
0 Kudos
Message 2 of 4
(2,731 Views)


@Alex67 wrote:

I've tried VI which calls dll function explicitly. Situation is the same. The next is a part of dll log file with my comments. They told me that process attached detached messages correspond to dll load unload. Is this normal that LV loads dll so many times? I've found in one topic of this forum that LV loads dll when a VI containing dll call is loaded. But in my case I can see a lot of "ATTACHED" massages at run time. There are also a few "DETACHED" messages at run time. Do you think this is normal LV behavior to unload dll at run time?

 
[25.06.2008] [15:31:23] PROCESS ATTACHED m_hwnd :: (1) 0x00000000
[25.06.2008] [15:31:24] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:31:24] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:31:25] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
LV project started
[25.06.2008] [15:31:46] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
Test VI loaded.
Starting Test VI...
[25.06.2008] [15:32:17] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:32:20] PROCESS ATTACHED m_hwnd :: (2) 0x00220378
[25.06.2008] [15:32:20] PROCESS ATTACHED m_hwnd :: (2) 0x00220378
[25.06.2008] [15:32:46] PROCESS DETACHED m_hwnd :: (3) 0x00220378
[25.06.2008] [15:33:18] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:33:30] PROCESS ATTACHED m_hwnd :: (2) 0x0030036E
[25.06.2008] [15:33:30] PROCESS ATTACHED m_hwnd :: (2) 0x0030036E
[25.06.2008] [15:33:30] PROCESS ATTACHED m_hwnd :: (2) 0x0030036E
[25.06.2008] [15:33:30] PROCESS ATTACHED m_hwnd :: (2) 0x0030036E
[25.06.2008] [15:34:23] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:36:15] PROCESS DETACHED m_hwnd :: (3) 0x0090039A
[25.06.2008] [15:37:00] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:37:12] PROCESS ATTACHED m_hwnd :: (2) 0x009B03EE
[25.06.2008] [15:37:12] PROCESS ATTACHED m_hwnd :: (2) 0x009B03EE
[25.06.2008] [15:37:12] PROCESS ATTACHED m_hwnd :: (2) 0x009B03EE
Test stoped.
[25.06.2008] [15:37:48] PROCESS ATTACHED m_hwnd :: (2) 0x00000000
[25.06.2008] [15:37:52] PROCESS DETACHED m_hwnd :: (3) 0x00000000
[25.06.2008] [15:37:52] PROCESS DETACHED m_hwnd :: (3) 0x00000000
[25.06.2008] [15:37:53] PROCESS DETACHED m_hwnd :: (3) 0x00000000
Test VI unloaded.
[25.06.2008] [15:38:39] PROCESS DETACHED m_hwnd :: (0) 0x00000000
LV project unloaded.


The problem is probably in the dynamic invocation of your VIs. A VI that loads a DLL has to take care to unload it when it is unloaded itself. Otherwise the DLL stays lingering in memory. So that is what LabVIEW does. As soon as a VI that loaded a DLL goes out of memory it unloads that DLL too.

Each Call Library Node in a diagram loads the DLL explicitedly when it is loaded itself into memory and unloads it when it goes out of memory. As soon as the DLL is loaded at least once the additional loads will simply increment a reference counter for that DLL and on unlodaing that reference counter gets decremented and when it reaches 0 Windows will unload the DLL from memory.

If your DLL has trouble with that since it stores resources globally between calls, then you need to make sure that at least one VI that references that DLL stays in memory for as long as that DLL is needed. You could do that by adding a VI that loads a function from that DLL to a place in your main application that is always in memory for the duration of your application. Or extend the INTERFACE class to hold on to an Initiliaze function for each possible interface that gets derived from it, or whatever.

Just have one VI that does not get unloaded whenever the SPI class decides that it is not currently needed anymore.

Rolf Kalbermatter


Message Edited by rolfk on 06-25-2008 12:16 PM
Rolf Kalbermatter  My Blog
DEMO, Electronic and Mechanical Support department, room 36.LB00.390
0 Kudos
Message 3 of 4
(2,725 Views)
Thanks Rolf!
0 Kudos
Message 4 of 4
(2,705 Views)