The FreeLibrary() API Function is to be used to release memory that is being used by a specific DLL File.
At times, programmers forget to add a simple Function call which does result in unnecessary usage of Memory.
QUOTE
My question is, therefore, if there are some undeleted memory that are heap
allocated by a DLL, are these released automatically when the DLL is detached from the calling process or do they remain in the heap as long as the application calling the DLL is running?
That depends.
If you're accessing the DLL file using one of .NET Framework's Classes, you don't need to worry about Memory Management. The Class takes care of that on its own.
But if you are using direct API Function Calls, you will need to free memory yourself.
QUOTE
I have the same question
regarding global variables declared and used in a DLL.
Global Variables lose scope as soon as the DLL file is detached.
Here's some info from MSDN:
QUOTE
Each process maintains a reference count for each loaded library module. This reference count is incremented each time LoadLibrary is called and is decremented each time FreeLibrary is called. A DLL module loaded at process initialization due to load-time dynamic linking has a reference count of one. This count is incremented if the same module is loaded by a call to LoadLibrary.
Before unmapping a library module, the system enables the DLL to detach from the process by calling the DLL's DllMain function, if it has one, with the DLL_PROCESS_DETACH value. Doing so gives the DLL an opportunity to clean up resources allocated on behalf of the current process. After the entry-point function returns, the library module is removed from the address space of the current process.
Hence, a missing FreeLibrary() call would prevent the DLL from being unmapped even though it is not in use.