6

From the MSDN document, we can see that, we should not call LoadLibrary/FreeLibrary in the DllMain entry point function.

The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary) during process termination, because this can result in a DLL being used after the system has executed its termination code.

My question is: Can we call FreeLibrary from ExitInstance()? for example:

Test.exe - main executable

HINSTANCE hDllMFC = LoadLibrary(L"TestApp.dll");
if (hDllMFC != NULL)
{
    FreeLibrary(hDllMFC);
}

while unload the hDllMFC, the call stack looks like:

TestApp.dll!CTestAppApp::ExitInstance() Line 42 C++
TestApp.dll!InternalDllMain() Line 155  C++
TestApp.dll!DllMain() Line 272  C++
TestApp.dll!__DllMainCRTStartup() Line 512  C
TestApp.dll!_DllMainCRTStartup() Line 477   C
ntdll.dll!LdrpUnloadDll()   Unknown
ntdll.dll!LdrUnloadDll()    Unknown
KernelBase.dll!FreeLibrary()    Unknown
Test.exe!wmain() Line 17    C++

TestApp.dll - Regular DLLs dynamically linked to MFC

CTestApp theApp;
HINSTANCE hDllResource = NULL;

BOOL CTestApp::InitInstance()
{
    hDllResource = ::LoadLibrary(L"TestApp_Resource.dll");

    return CWinApp::InitInstance();
}

int CTestApp::ExitInstance()
{
    ::FreeLibrary(hDllResource);

    return CWinApp::ExitInstance();
}

TestApp_Resource.dll - Regular DLLs, resource

...

I think we should not, but from the implmentation of CWinApp::ExitInstance(), we can see that, it was also trying to unload the resource dll. Does that mean we can call FreeLibrary in the ExitIntance()?

int CWinApp::ExitInstance()
{
  //... 

 if (m_hLangResourceDLL != NULL)
  {
    ::FreeLibrary(m_hLangResourceDLL);
    m_hLangResourceDLL = NULL;
  }
  //...
}

I also found a document which confirm there is a bug while calling FreeLibrary from ExitInstance in Win95.

BUG: Assert When Calling AfxFreeLibrary from ExitInstance http://support.microsoft.com/kb/187684

STATUS: Microsoft has confirmed this to be a bug in Windows 95. We are researching this bug and will post new information here in the Microsoft Knowledge Base as it becomes available.

adshuangjoh
  • 281
  • 2
  • 12
  • There is no point releasing DLLs when you call ExitInstance(). The DLL will get automatically unloaded anyway a few milliseconds later when the process terminates. – Hans Passant Dec 26 '12 at 15:50
  • Since CWinApp is declared in the main executable, its ExitInstance is not called from DllMain (among other reasons, because executables do not have a DllMain). The question is therefore moot. – Raymond Chen Dec 26 '12 at 18:43
  • @RaymondChen, thanks, I have refined my question that TestApp.dll is a Regular DLLs dynamically linked to MFC, so the ExitInstance() was called in response to the DLL_PROCESS_DETACH message in the InternalDllMain. – adshuangjoh Dec 27 '12 at 01:53
  • the callstack of unloading TestApp.dll has been post inline the question. – adshuangjoh Dec 27 '12 at 02:01

1 Answers1

5

If in fact ExitInstance is being called from DllMain (as confirmed by the stack trace) then all the rules for DllMain apply, including the prohibition on loading or unloading other DLLs recursively. (Note that putting your CWinApp in a DLL is highly unusual and MFC may have other issues with it, such as the one noted in the KB article. Not saying that there are or are not any more issues lurking, but adding a note of additional caution.)

Raymond Chen
  • 44,448
  • 11
  • 96
  • 135
  • 2
    Seems like the FreeLibrary behavior has been changed in Win8, which mess up the MFC module state, appreciate if you could take a look that the related issue in the MSDN forum [here](http://social.msdn.microsoft.com/Forums/en-US/winforms/thread/c872ae41-98e7-43ed-92e8-38f1d68bc5ed) – adshuangjoh Dec 27 '12 at 04:23