Why does MFC call _CrtDumpMemoryLeaks ?!?

From:

"Martin T." <0xCDCDCDCD@gmx.at>

Newsgroups:

microsoft.public.vc.mfc,microsoft.public.vc.language,microsoft.public.vc.debugger

Date:

Fri, 11 Jul 2008 15:28:23 +0200

Message-ID:

<g57n5p$sfj$1@registered.motzarella.org>

(I think this applies to mfc & C++ & debugging, hence the 3 NG)

OK, maybe this'll be some kind of rant, but I really don't get it and it
would really be nice to know what the rationale behind the "built-in"
memory leak detection of MFC is, when any user could provide it on his
own without false memory leaks ...

Explanation:
The Run-Time Library provides for Debug Routines that (among other
things) allow reporting of memory-leaks.
It is possible to enable *automatic* reporting for the CRT by calling
the function _CrtSetDbgFlag(...) with the _CRTDBG_LEAK_CHECK_DF flag.
If you choose to enable this *automatic* check in your C++ program, the
CRT will happily (and most correctly) report all left-over memory via
_CrtDumpMemoryLeaks *after* basically all non-system DLLs have been
unloaded.

Enter MFC:
For reasons unknown to me (but probably historical or some such $%&$)
/if/ your Application links against the MFC DLL /then/ within the d'tor
of a class called _AFX_DEBUG_STATE (atlmfc/src/mfc/dumpinit.cpp, ln 123)
MFC will call _CrtDumpMemoryLeaks and afterwards disable the reporting
on process-end:
###################
_AFX_DEBUG_STATE::~_AFX_DEBUG_STATE()
{
#ifndef _AFX_NO_DEBUG_CRT
    _CrtDumpMemoryLeaks();
    int nOldState = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);
    _CrtSetDbgFlag(nOldState & ~_CRTDBG_LEAK_CHECK_DF);

    ASSERT(_CrtSetReportHook2(_CRT_RPTHOOK_REMOVE,_AfxCrtReportHook) != -1);
    _CrtSetDumpClient(pfnOldCrtDumpClient);
#endif // _AFX_NO_DEBUG_CRT
}
###################

Not only is this completely unnecessary, as you could (if you so wished)
tell the CRT to dump it on process end - oh no! It is quite horrible if
you use a 3rd party C++ DLL that happens to hold memory in global static
objects that will only be destroyed when this DLL is unloaded and does
*not* link against MFC.
That is because in all my test cases any user-supplied DLL (project
dependency, via Linker-Input:lib) is always unloaded *after* the MFC-DLL
(mfc80ud.dll in my case).
In this scenario the stupid call of _CrtDumpMemoryLeaks from the MFC
cleanup code will report all this memory as leaks, even though it *will*
be cleaned up --- it just happens that the code had the cheek to not use
MFC.

* You can't work around it, as you cannot change DLL (static)
load/unload order.
* You can't work around it, as you cannot use a C++ DLL with
LoadLibrary/FreeLibrary.
* You can't work around it, as you cannot tell MFC not to report this
false memleaks and use the CRT mechanism instead.
* You can't work around it, as your main application needs to use MFC.
* You can't work around it, as the 3rd party DLL cannot, in general, be
made to link against MFC (thereby forcing a later unload of mfc80ud.dll)
* You can't even ignore the MFC dump and additionally use the CRT dump
as MFC will switch it off after it dumped!

Bah!

So ... I'm stuck with a program that dumps 2000 memory leaks at
MFC-cleanup that are false and will obscure any real (and possibly
problematic) memleaks I would like to find ...

It would be interesting to hear from someone who knows a rational behind
the MFC code or has some general thoughts how to get around it or to
hear why I'm completely mistaken :)

cheers,
Martin