My program structure is:
1. [web interface]
2. [my managed code DLLs: C#]
3. [my proxy layer DLL: managed C++ classes mapping to unmanaged C++
classes] => manually does the crt-init and crt-terminate calls
4. [my pure unmanaged DLL] -- this is accessed by the unmanaged C++
classes in (3) using LoadLibrary and FreeLibrary
5. [third party DLLs and Windows DLLs including MFC71] => statically
links with MFC71, but dynamically links using LoadLibrary/FreeLibrary
with third party DLLs.
Problem:
When I use the .NET Memory Profiler tool, I appear to have a problem
with my third-party unmanaged DLLs leaking memory that they normally
would not leak with a standard Windows program. However, when I
unload the DLLs from within the .NET environment, the Visual Studio
..NET debugger does not report any memory leaks.
For example, with one third party DLL that loads a 9MB DAT file when
it initializes, the committed memory leak is slightly larger than the
DAT file everytime I load and unload the third party DLL using
LoadLibrary and FreeLibrary from my pure unmanaged C++ DLL, and within
..NET Memory Profiler under "Committed Memory -- Potentially Shared --
this growing leak is tied to the dat file that the third party DLL
loads and unloads. If I put this code in a tight loop of load and
unload on the third party DLL, it quickly eats up committed memory
until things start to fail after maybe 1500 cycles. If I keep a third
party DLL in memory by not decrementing its LoadLibrary reference
count to zero, in the .NET Memory Profiler the .DAT file does not grow
beyond 9MB within the committed memory pane: it only grows if it is
actually unloaded and reloaded.
Does anyone have any clues on what might be wrong?
Any suggested Microsoft KB articles I should read?
Any free pizza?
