Bizarre DLL problem

[ark]

Ok, I've got two different DLLs with the same set of exported functions, and I'm having a weird problem. Because of the nature of the program, I have gone with LoadLibrary to link the DLL rather than using the .lib file that Visual C++ exports.

It is convenient in using the program to be able to change which DLL is being used at run-time by "disconnecting" from one and "connecting" to the other, which means I need to call FreeLibrary and leave the user application running.

When the application uses one of the DLLs, there are no problems. When it uses the other, the program exits without warning and with no error message at some point soon after the call to FreeLibrary (but not during or immediately after). The problem definitely relates to FreeLibrary because commenting that line out makes the problem not occur (but obviously the DLL doesn't get unloaded when it's no longer needed).

When I run the debugger, I do get an error message -- an access violation (at a seemingly random point after the FreeLibrary call). But the point where the error occurs is a bunch of assembly language, and when I look at the call stack, all I see is a bunch of NTDLL! entries with hexadecimal numbers beside them. There are no entries for any of the functions in either the DLL or the application.

Any ideas what might be happening?

[Tim]

It looks to me like either:
1. You're still trying to call functions in the old DLL after FreeLibrary was called.
2. There's a bug in your DllMain function.

To check whether (1) is a problem, you could try setting the two DLLs' base addresses to different values (you should do this anyway, to prevent relocation when they are loaded). In VC++, go through the Project Settings dialog, Link page.

[ark]

would I be looking for the hex number after NTDLL! to be different? if so, then changing the base address doesn't change anything.

I don't think it's too likely to be a function call after FreeLibrary is called, because:

1. the functions in the DLL aren't called that often and are, in general, only called as a direct result of some user action

2. both DLLs are used exactly the same way by the program -- the idea is to provide a buffer between two varying implementations; that is, when the functions are called doesn't change, it's what they do behind the scenes that changes -- if it were just a function call being made after the FreeLibrary call I would expect to see the same behavior when using either DLL.

I don't think it's too likely to be a problem in the DllMain, either, since both DllMains are exactly the same and are super-simple at that:

Code: Select all

int WINAPI DllMain(HINSTANCE hinst, DWORD dwReason, void* pvReserved)
{
    switch(dwReason)
    {
    case DLL_PROCESS_ATTACH:
        // save the instance handle to a global
        g_hinstDLL = hinst;
        break;
    }
    return true;
}

that's just from memory so I don't know if that's exactly right, but that's basically all there is to it.

[Tim]

would I be looking for the hex number after NTDLL! to be different? if so, then changing the base address doesn't change anything.

You would expect an access violation instead of what you're seeing, since the FreeLibrary would remove the old DLL from memory, and the next LoadLibrary would put the new one at a different adress.

I don't think it's too likely to be a problem in the DllMain, either, since both DllMains are exactly the same and are super-simple at that:

Maybe it's a problem in the destructor for a global C++ object. Constructors and destructors get called from the C library's DllMain (actually DllMainCRTStartup).

[ark]

ok, probably should have been a little clearer. the problem only occurs with one of the DLLs and it doesn't matter if the other one is loaded first, or at all.

a global object is a possibility...i'll have to look at it to see if there are any.