>>...An MFC application is reporting many memory leaks at exit using MFC's internal mem leak checker...

Eric,

This is a really old story and, unfortunately, I see that another developer experienced it. I reported to Microsoft a memory leaks problem ( I called it as An Internal MFC Memory Leaks ) with MFC some time in 2006 and their response was:

'...this is a problem with your application...'

and I knew that my codes did Not Have Any memory leaks. Their response "ignited" my interest in implementation of my own absolutely portable and as simple as possible Memory Leaks Detection software subsystem ( implemented in 2007 and currently used on another project ).

So, I'll follow up on your post later with more details. Would you be able to provide a small test case without Boost library and with 32-bit configuration ( without 64-bit configuration )?

Inspector XE Update 4 contains some fixes for handling MFC's debug 'new'.   The problem shows up as false reports of mismatched allocation/deallocation - IXE would miss the debug 'new', but catch the underlying malloc.   It would subsequently see the 'delete', and report a problem.

Unfortunately, I don't think this fix will address the issue you're seeing, but it still may be worth trying the latest IXE update.

>>...For years I didn't have any issues with MFC's memory leaks detector, it was very useful, only lately I came across this issue
>>in a mature application...

More technical details? A piece of code?

>>...But before doing reverse engineering...

MFC is provided with sources and step into the code always helps to understand what is going on. Microsoft doesn't hide anything in the library and, to some degree, it could be considered as Open Source.

>>...maybe someone has some insight on the matter and maybe a workaround.

Could you post the Memory Leaks report from the Output Window of your Visual Studio? Your current description is too generic, however, I can list three possible problems:

- A memory allocation / deallocation problem in your C/C++ application ( memory leaks )
- A memory allocation / deallocation problem in Boost library ( memory leaks )
- A memory allocation / deallocation problem in MFC library ( memory leaks )

and please consider All of them during investigation.

Q: Does MFC use a custom allocator (e.g. not malloc) and thus fools Inspector XE?

No and It doesn't "fool" Inspector XE. The core of memory leaks detection API for MFC is very old and possibly was implemented some time between 1992 and 1994 ( in Visual C++ v1.5 / v2.0 ) when, as far as I know, Inspector XE did Not exist. There is No Any reason to "fool" Any software.

Q: Can I somehow disable MFC's special memory allocator in debug builds?

Please explain me how is it going to fix memory leaks? Or, you're simply interested to verify what Inspector XE will report?

1. As soon as CRTDBG_MAP_ALLOC is defined then malloc is mapped to malloc_dbg. Take into account that there is a set of CRT-functions for allocation / deallocation of alligned memory ( it is documented in MSDN ).

2. A call to _CrtSetDbgFlag( 0 ) disables reporting.

Q: Are the leaks reported falsely by MFC if Inspector XE says nothing's wrong?

No. If MFC detects a memory leaks and Inspector XE doesn't then there is a problem / issue with memory leaks detection in Inspector XE.

>>... Are the leaks reported falsely by MFC...

I'd like to make a special post regarding a term False Memory Leaks widelly used by some software engineers:

If MFC memory leaks detection API ( based on _Crt<...> functions ) Reports a memory leaks it is Not a False one, and it is a Real one.

>>...The code is an internal tool and I can't publically send pieces of it. When there were leaks in the executable
>>(vs the DLLs) MFC reported them - it included a source name+line number in the report.

It is not clear for me how anybody could help you if no technical details provided.

>>...It's possible to "fool" memory checkers by replacing malloc/new/new[] with different functions...

MFC doesn't do it with '...different functions...'. We're not speaking about anything else, right?

>>...If I remember correctly, malloc_dbg is identified by Inspector...

This is incorrect and you need to look at malloc.h and crtdbg.h header files. Or you can see it when debugging ( simply step into the code when malloc/new is called ).

>>...I've read reports that if globals are instantiated (and malloc) before MFC is loaded that can happen...

Web-link(s) for these reports, please. I'd like to review these reports and at the moment I consider your statement as some kind of "speculation". In order to verify if some DLL(s) is/are loaded before MFC DLLs do the following:

- Start your application in Debugger
- Don't do anything
- Exit your application
- Review order of loaded DLLs in Visual Studio's Output WIndow ( find all references for MFC, Boost, etc DLLs )
- Review order of unloaded DLLs in Visual Studio's Output WIndow
- And one more, Is there a memory leaks dump?

>>...I reported to Microsoft a memory leaks problem ( I called it as An Internal MFC Memory Leaks ) with MFC
>>some time in 2006...

I found the report in my records:

//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// DevNote #0004 - An Internal MFC Memory Leaks

If a call to _CrtDumpMemoryLeaks() is done it detects some Memory Leaks for an MFC-based application:

[ Codes deleted ]

A Visual Studio's Output Window looks like:
...
Detected memory leaks!
Dumping objects ->
...\atlmfc\src\mfc\dllmodul.cpp(133) : {84} client block at 0x0036B7B0, subtype c0, 64 bytes.
a CDynLinkLibrary object at $0036B7B0, 64 bytes
{79} client block at 0x0036B5A0, subtype c0, 64 bytes.
a CDynLinkLibrary object at $0036B5A0, 64 bytes
{69} client block at 0x00367190, subtype c0, 64 bytes.
a CDynLinkLibrary object at $00367190, 64 bytes
Object dump complete.
...
This is by design of the MFC! The MFC creates several objects of CDynLinkLibrary
type when processing DLL_PROCESS_ATTACH event in InternalDllMain() function,
and deletes these objects of CDynLinkLibrary type when processing
DLL_PROCESS_DETACH event. That is, just before unloading the DLL from memory.

Since DLL_PROCESS_DETACH event is processed later a call to _CrtDumpMemoryLeaks()
detects that some objects are still NOT deleted. Remember, that all objects of
CDynLinkLibrary type are MFC-Internal objects. But, if references to some
another objects appear in the Output Window it means that the Application has
Memory Leaks.

>>A few links for false MFC leaks:
>>
>>http://stackoverflow.com/questions/628021/false-memory-leaks-in-a-mfc-pr...
>>
>>http://binglongx.wordpress.com/2009/05/28/false-memory-leaks-detected-in...

I'll take a look and respond regarding a concept 'False Memory Leaks'.

>>...This scenraio is just opening and closing the app.
>>
>>MFC DLL (mfc100d.dll) is loaded around the middle of load list.

Could you post to the thread or e-mail me ( using Private Messaging system ) that list?

As soon as you're back to work:

1. In your Visual Studio create a new MFC project and it should match to what you have, Dialog-based ( DLG ), SDI-based, or MDI-based test application
2. Build the test application
3. Start the test application in Debugger
4. Don't do anything
5. Exit the test application
6. Is there a memory leaks dump?
7. Add that code in OnInitDialog ( for DLG ) or in InitInstance ( for SDI & MDI ):
...
#define _SIMULATE_MEMORYLEAKS // Use that macro to control simulation of memory leaks / #undef when you don't need it
...
#ifdef _SIMULATE_MEMORYLEAKS
char *pchBuffer = NULL;
pchBuffer = new char[ sizeof( char ) * 777 ];
#endif
...
8. Repeat steps 2 to 6
9. Add Boost headers and libraries ( Don't add any functionality yet )
10. Repeat steps 2 to 6
11. Add some MFC functionality that is used in your production application ( It could be a difficult process )
12. Repeat steps 2 to 6
13. Add some Boost functionality that is used in your production application ( It could be a difficult process )
14. Repeat steps 2 to 6

and so on.

The main idea is as follows: you need to use a very clean test application in order to reproduce the same memory leaks. If you manage to use a similar approach in your production application it will also work and in that case you will need to start commenting out some pieces of codes. It means, as soon as memory leaks are Nor detected a last commented piece of codes is the root cause of these memory leaks.

You have ~50 memory leaks and I'd like to share my experience: in 2007 in some 3-D imaging application ( MFC & QT & Internal libraries ) due to some problems we had to deal with more than 30,000 memory leaks.

A couple of project organization advises. A very strict approach in the development process is as follows:

- A developer is Not allowed to check in codes if codes are Not pass a review by another software developer
- A developer is Not allowed to check in codes if codes are Not checked for memory leaks
- Every (!) class, function, macro, etc must have an independent test case ( For example, for a middle size project I have more than 45,000 code lines of different tests )

I believe that in two cases ( web-links you've provided ) developers detected some memory leaks. However, in the 1st case a developer uses a third part DLL and in both cases memory leaks dump are Not provided. Another thing is ( from the 1st web-link ):

...Those leaks are legitimate...

My question is what are legitimate leaks?

PS: Sorry for a completely different example. Let's imaging,,, A Person calls to a City of Abc to report a problem and here is a conversation with an Operator:

Caller: Hi, I have a water leak in my basement!
Operator: How bad is it?
Caller: It is around 10-15cm of water...
Operator: Don't worry, it is a legitimate water leak...
or
Operator: Don't worry, it is a false water leak...

What would you tell to Operator?

Thanks for the update, Eric.

I also would like to mention that all cases when container classes are used, MFC, or STL, or Boost, need to be verified as well. Unfortunately, all these verifications are time consuming when application is mature and has hundred of thousands code lines.

Please keep everybody informed.