Call Library Function & DLL Attach and Detach Calls

[KenRiley]

Exactly - the process attach, detach, and so on messages are called at the discretion of the operating system. LabVIEW provides its own sequence of calls to provide platform independence. The callbacks that are being exposed in the next version of LabVIEW provide user hooks into the sequence. The reserve callback is called when the VI itself is reserved for execution and the corresponding unreserve callback will be called when the VI is unreserved. The abort callback will be called during abort processing of the dll and will then be followed by the call to the unreserve callback when the subsequent unreserve occurs. Hope this helps!! Ken

[rolfk]

---

@Tomi M wrote:
I used the code below.

#include <iostream>
#include <fstream>

BOOL APIENTRY DllMain( HANDLE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
                     )
{
    using namespace std;
    ofstream out("C:\log.txt", ios::app);
    switch (ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
        out << "DLL_PROCESS_ATTACH" << endl;
        break;
    case DLL_THREAD_ATTACH:
        out << "DLL_THREAD_ATTACH" << endl;
        break;
    case DLL_THREAD_DETACH:
        out << "DLL_THREAD_DETACH" << endl;
        break;
    case DLL_PROCESS_DETACH:
        out << "DLL_PROCESS_DETACH" << endl;
        break;
    }
    return TRUE;
}

Tomi

---

LabVIEW simply uses LoadLibrary() to load a shared library into memory. It has no direct control of how Windows will initialize that DLL inside the LoadLibrary() function. It may be that the DLL is already loaded somewhere, somehow or that Windows decides that it needs not to initialize the DLL anymore. As to why and how this could happen you would be better of asking MS or some low leverl Windows API guru, not NI.

Have you tried to create a test app that loads your DLL with LoadLibrary() and frees it afterwards with FreeLibrary() to see how it works there? Unless you can proof that it is different there, there is absolutely no use in trying to investigate an issue in LabVIEW of which you don't even know if it is somehow LabVIEW related. The multiple PROCESS_DETACH might be related to multiple FreeLibary() calls by LabVIEW in different situations to make sure the DLL is always properly purged. Windows has a somewhat strange refcount for DLL loads that can lead especially in multi-threading applications to the situation that eventhough you matched every LoadLibrary() call with a FreeLibrary() call, the DLL still remains in memory until the parent process completely terminates.

Rolf Kalbermatter