Heap corruption after FreeLibrary?

Question

In a solution of several dynamic linked libraries a heap corruption occurs every time basically with only one single library "MyLibrary.dll", but not lets say for "MyOtherLibrary.dll". The relevant piece of code:

HINSTANCE hModule;

hModule = LoadLibrary("MyLibrary.dll");

// hModule is checked and definitely valid  

if(hModule)
{
    FreeLibrary(hModule);   // HeapCorruption occurs now, but ONLY for "MyLibrary.dll"
}

I really don't figure out what is going wrong. It seems to me that i have to change something in the VS project settings but i have no clue either what to change nor why. Could it be some piece of code inside the library as well?

Additional Info: The project of "MyLibrary.dll" was created with CMake 2.8 and build successfully with Visual Studio 2010 SP1 (but the project "MyOtherLibrary.dll" as well).

Can anybody help please?

Answer 1

After quite a long search (which was really pain in the ass for a non-MVP) it turned out to be related to the runtime libraries like some of you guessed and answered already.

But the problem actually was not the runtime library itself that i was linking to (libcmt.lib) but the runtime library i set to ignore in the project (it wasn't libcmtd.lib).

According to this page of microsoft you have to carefully keep an eye on which library to ignore depending on which one you are using. Now i am wondering why no linker warning occured..but that's a different topic.

Anyway thanks a lot for your help!

Answer 2

 // HeapCorruption occurs now, but ONLY for "MyLibrary.dll"

The comment is wrong. It should say

 // HeapCorruption is detected now.

Which is a very common scenario, when code terminates then it is likely to have some memory to release that has been in use for a while. Giving ample opportunity to get that memory corrupted by pointer bugs and buffer overflows in your code. Or get a diagnostic from the debug heap when the EXE and the DLL use different CRT versions. That kind of heap damage goes undetected, until the heap manager needs to visit that memory to release it. Kaboom then.

Use the debug allocator available from <crtdbg.h> to catch that kind of corruption earlier. Many debugging tools available in general to troubleshoot heap corruption bugs.