1

I have an MFC application that consists of a main app and a lot of MFC extension DLLs. It also has extension resource DLLs containing all the resources. I noticed that the application did not report memory leaks as MFC apps usually do once I left a memory leak. I traced through it all and found that the MFC memory leak reporting mechanism is through the class _AFX_DEBUG_STATE. Comparing with a standard wizard based MFX application, I do have a _AFX_DEBUG_STATE object instantiated in dumpinit.cpp:

static BOOL _afxDiagnosticInit = AfxDiagnosticInit();

Basically the initialization of the memory leak reporting mechanism is identical in my application and in the wizard generated MFC app.

There is a static object called afxDebugState which is defined as:

extern CProcessLocal<_AFX_DEBUG_STATE> afxDebugState;

The call stack for when it is created is:

mfc120ud.dll!_AFX_DEBUG_STATE::_AFX_DEBUG_STATE() Line 109  C++
mfc120ud.dll!CProcessLocal<_AFX_DEBUG_STATE>::CreateObject() Line 229   C++
mfc120ud.dll!CProcessLocalObject::GetData(CNoTrackObject * (void) * pfnCreateObject) Line 462   C++
mfc120ud.dll!CProcessLocal<_AFX_DEBUG_STATE>::GetData() Line 215    C++
mfc120ud.dll!AfxDiagnosticInit() Line 135   C++
mfc120ud.dll!`dynamic initializer for '_afxDiagnosticInit''() Line 20   C++
msvcr120d.dll!_initterm(void (void) * * pfbegin, void (void) * * pfend) Line 955    C
mfc120ud.dll!_CRT_INIT(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 295   C
mfc120ud.dll!__DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 502 C
mfc120ud.dll!_DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 472  C

However the destructor of the object is called in the wizard app, but never in my app, hence I don't have the memory leak dumping mechanism.

Can anybody shed any light on that one?

Thanks

Ajay
  • 18,086
  • 12
  • 59
  • 105
langlais
  • 21
  • 3
  • Move the `_afxDiagnosticInit` object from the DLL to your main executable image. You cannot perform reliable memory leak detection in a DLL's unload handler anyway, since you have no control over when your DLL gets unloaded. – IInspectable May 20 '16 at 16:08
  • Well the problem is that I do not have the possibility of moving it out, since it is part of MFC, and MFC is used in DLLs, just as in the wizard generated app. – langlais May 22 '16 at 09:17
  • I think the problem is because we have one DLL that imports a CLR component and the CLR takes over deletion of global objects. It is described [here] (http://stackoverflow.com/questions/13632187/destruction-of-native-objects-with-static-storage-duration) I couldnt find a way to go around it, so I have tried implementing my own using the _Crtxxx routines but they report hundreds of leaks as some global static objects get deleted after the reporting. I'm none the wiser as to how to solve this problem, any help much appreciated – langlais May 24 '16 at 14:12

0 Answers0