Article ID: 167929 - Last Review: November 21, 2006 - Revision: 4.1

Memory leaks are reported when you use multiple MFC DLLs

View products that this article applies to.
System TipThis article applies to a different operating system than the one you are using. Article content that may not be relevant to you is disabled.
This article was previously published under Q167929
Expand all | Collapse all

SYMPTOMS

When you debug a project that contains MFC regular (USRDLL) DLLs or ActiveX Controls (OCX), you may see memory leaks similar to the following reported in the debugger: 
   a CDynLinkLibrary object at $00410F70, 64 bytes long
   a CDynLinkLibrary object at $00410F70, 64 bytes long
   {38} client block at 0x00410D80, subtype 0, 64 bytes long.
   a CDynLinkLibrary object at $00410D80, 64 bytes long
   a CDynLinkLibrary object at $00410D80, 64 bytes long
   {36} client block at 0x00410C60, subtype 0, 64 bytes long.
   a CDynLinkLibrary object at $00410C60, 64 bytes long
   a CDynLinkLibrary object at $00410C60, 64 bytes long
Back to the top

CAUSE

These memory leaks are reported when multiple versions of the MFC DLL are loaded in the same process. Since MFC extension (AFXDLL) DLLs require the exact same MFC DLL as the call application, this problem can only occur when using MFC regular (USRDLL) DLLs or ActiveX Controls (OCX) that use the shared version of MFC.

The most common case is mixing ANSI (MFC4xd.DLL) and UNICODE (MFC4xxUd.DLL) versions of MFC in the same process. This can also occur when mixing MFC42d.DLL and MFC40d.DLL.
Back to the top

RESOLUTION

These memory leak notifications are false, and can be ignored. Since neither copy of MFC knows about the other ones, it's not easy to stop these false leaks from being reported. However, it is possible to separate the false leaks from the potential real leaks. This can be done by overriding CWinApp::ExitInstance() in both the EXE and DLL and placing TRACE() statements in them: 
   int CTestDllApp::ExitInstance()
   {
      TRACE(_T("ExitInstance() for regular DLL: TESTDLL\n"));

      return CWinApp::ExitInstance();
   }
Only the memory leaks that are detected after the last CWinApp::ExitInstance() is called are true memory leaks.
Back to the top

STATUS

This behavior is by design.
Back to the top

MORE INFORMATION

Consider the following application/DLLs: 
     -------------               --------------
     =           =               =            =
     =   MFC     =    Calls      =    MFC     =
     =   APP     = ------------> =   USRDLL   =
     =           =               =            =
     =           =               =            =
     -------------               --------------
           |                           |
           |                           |
           | Calls                     | Calls
           |                           |
           \/                         \/ 
     -------------               --------------
     =           =               =            =
     =           =               =            =
     =   MFC40d  =               =   MFC40Ud  =
     =    DLL    =               =    DLL     =
     =           =               =            =
     -------------               --------------
                \                 / 
                 \               / 
                  \ Calls       / Calls
                   \           / 
                   \/         \/ 
                   -------------
                   =           =
                   =           =
                   =  MSVCR40d =
                   =   (CRT)   =
                   =           =
                   -------------
The MFC Application that is built with the ANSI (MFC40d.DLL) version of MFC calls the MFC USRDLL, which is built with the UNICODE (MFC40Ud.DLL) version of MFC. Both MFC versions use the same C run-time (CRT) DLL, MSVCR40d.DLL. Since MFC USRDLLs are "black-boxes", there should be no problems with calling a UNICODE MFC USRDLL from an ANSI MFC Application.

However, since the UNICODE (MFC40ud.DLL) and ANSI (MFC40d.DLL) MFC DLLs both use the same CRT DLL, false memory leaks are reported on all the objects allocated in the MFC USRDLL. This occurs because MFC relies on the CRT DLL to allocate and track all memory. It does not separate the memory allocations from the different versions of MFC. When one of the MFC DLLs unloads, it calls the CRT to do a memory dump, assuming everything left in the heap is a memory leak. However, this assumption is incorrect since there are two multiple copies of MFC in memory.

(c) Microsoft Corporation 1997, All Rights Reserved. Contributions by Kelly Marie Ward, Microsoft Corporation.
Back to the top
APPLIES TO
  • Microsoft Foundation Class Library 4.2, when used with:
    • Microsoft Visual C++ 4.0 Standard Edition
    • Microsoft Visual C++ 4.1 Subscription
    • Microsoft Visual C++ 4.2 Enterprise Edition
    • Microsoft Visual C++ 4.2 Professional Edition
    • Microsoft Visual C++ 5.0 Enterprise Edition
    • Microsoft Visual C++ 5.0 Professional Edition
    • Microsoft Visual C++ 6.0 Enterprise Edition
    • Microsoft Visual C++ 6.0 Professional Edition
    • Microsoft Visual C++, 32-bit Learning Edition 6.0
Back to the top
Keywords: 
kbtshoot kbdll kbprb KB167929
Back to the top