As I understand it, it MAY be executed and MEANT to be executed sometimes (for example, in case of dll injection using CreateRemoteThread and other methods). In this way,
FreeLibraryAndExitThread(hModule, 0)
will do just that.
On the other hand, causing
FreeLibrary(hModule)
will not be here - from MSDN: "If they called FreeLibrary and ExitThread separately, the race condition would exist. The library could be unloaded before calling ExitThread." As a remark, ExitThread does some accounting, and not just returns a stream function.
All this assumes that your Dll received the hModule itself by calling LoadLibrary from the loaded Dll, or rather by calling the following function from within the loaded Dll:
GetModuleHandleEx ( GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS, (LPCTSTR)DllMain, &hModule )
This increases the reference counter for the Dll, so you know that if you later free the library using this descriptor, and if the library is really unloaded, then you had the last link to it.
If you instead skip the increment of the Dll reference counter and get hModule only from argument to DllMain during DLL_PROCESS_ATTACH , then you should not call FreeLibraryAndExitThread , since the code that loaded the Dll still uses it, and this module does not really control yours.
source share