I will try that. Thank you.

However, the question to whether or not Intel Inspector XE "supports COM and ATL" is unanswered. I suspect not. Should I be getting all of these entries from the inspector? How do I know if any of them really leak or if they are all false positives? Is it known that every COM call results in an inspector entry? Is there some chance of leakage in mashalling and unmarshalling?

I know my project leaks or grows. Something is amiss. However, inspector is not giving me any entries in source code that I control. I am rather lost as to how to narrow down the problem.

Here is one small example and it doesn't even instantiate a COM object yet. It causes inspector to generate 1 missing allocation item, 2 kernal resource leak items, 2 invalid memory acces items, when running m1:

#include

#include

#include

#include

//-----------

int main()

{

CoInitialize(NULL);

CoUninitialize();

return 0;

}

Does CoInitialize really leak? Probably not.
Add in Any _com_ptr and call create instance on it and it gets worse.
Add in a call to any method on that instance and you get more.
Now bring some threads into the mix and you can get spammed with hundreds of entries.

It's really notas simple as "in or out of COM". user code could be inside a COM object. Sometimes the profiler complains about marshalling/unmarshalling and the user could have done it incorrectly. Sometimes the user forgets to call release on an interface pointer and did not use a smart pointer. These kinds of things are what we need to look for but cannot spot because of the hundreds of falsepositives that get generated.

If I filter the inspector to only look at the calling code, how then can I see if my code inside the COM object leaked? Or how can I tell if I screwed up using a BSTR than I got control of but did not release? In essense, how can I unit test my implementation in a COM object for memory leaks?

I've taken to doing my best to make proxies for COM interfaces, seperating out COM class implementations into seperate classes, but it is really making things difficult and some of them arejust impossible to test at all.I can't just turn to my boss and say, "Well, let's not use COM/ATL anymore and spend the next few years replacing it, because we will never find a memory profiler that works with it."

BTW, how do I include more than an executable in the module filter? I've only seen examples limited to the .exe itself. How can I cover the .exe and a .dll or two? Say I have a "utility.dll" with some math functions in it or something.

This doesn't seem to work. Making a list seperated by commas runs, but it doesn't yield any results.

I went and purposely put a memory leak in my unit test and ran it with the following:
inspxe-cl -collect mi3 -module-filter-mode=include -module-filter=DevTest_StatusClient.exe,CommonLibd.dll -- DevTest_StatusClient.exe

0 problems Found.

Then I ran it with:
inspxe-cl -collect mi3 -module-filter-mode=include -module-filter=DevTest_StatusClient.exe -- DevTest_StatusClient.exe

1 New Problem Found

Both should have found the problem. the spellings of the modules are correct. I verified with process explorer that the dll name, spelling, and location is correct. Even if it wasn't, it shouldn't run as normal and report 0 problems.

//-------------------------

// main.cpp

// Project Includes

#include "precompiled-header.h"

#include "StatusClientTest.h"

#include "StatusSubscriptionTest.h"

#include "CachedDBDataTest.h"

int main()

{

int return_code = 0;

// return_code = StatusClientTest01();

// return_code = StatusSubscriptionTest01();

return_code = CachedDBDataTest01();

return return_code;

}

// CachedDBDataTest.h

#ifndef CACHEDDBDATATEST_H

#define CACHEDDBDATATEST_H

/// Creates CachedDBData object, fetches the data from the database, and repeatidly calls the accessors to the data

int CachedDBDataTest01();

#endif

//CachedDBDataTest.cpp

// Project Includes

#include "precompiled-header.h"

#include "ComtracifCallbackProxy.h"

#include "TssifProxy.h"

// Ssm Core Lib

#include "CachedDBData.h"

#include "GlobalStatusClient.h"

#include "SsmToComtracifImpl.h"

#include "SsmToTssif.h"

#include "StatusClientImpl.h"

#include "StatusUpdate.h"

#include "StatusSubscription.h"

// Shared Utility Includes

#include "SharedUtility/Configuration.h"

// Utility Library Includes

#include "Report.h"

// Boost Includes

#include

//------------------------------------------------------------------------------

int CachedDBDataTest01()

{

/*

try

{

// Initialize COM

CoInitialize(NULL);

// Create instances needed in specific order, due to circular dependencies

ATMS::ReportThreadSafeC * reporter = new ATMS::ReportThreadSafeC(L"DevTest");

ATMS::pReporter = reporter;

ConfigurationData::SharedPtr configurationData(new ConfigurationData());

ATMS::CachedDBData::SharedPtr cachedDBData = ATMS::CachedDBData::Create(reporter, configurationData);

cachedDBData->FetchAllPersistentData();

ATMS::pEnumConverter = &(cachedDBData->enumConverter_);

// Idle for 10 seconds to let the threads for objects we have created do their thing

// and the memory difference reading we get really represents what we do after this point

Sleep(10000);

// Get the initial count if base objects created by the DBLib

unsigned int numLeaked = CommonBaseC::GetNumInstances();

for(ATMS::RIDt rid = 0; rid < 1000; ++rid)

{

cachedDBData->lock_.Shared();

ATMS::DBVehicleDetectorC * dataItem = cachedDBData->vehicleDetectors_.FindByRID(rid);

cachedDBData->lock_.Release();

// We must call Release() manually on anything we obtain from the DBLib

// Bug 2706, 2710, 2711

if( dataItem )

{

dataItem->Release();

}

}

// Get the count if base objects created by the DBLib

numLeaked = CommonBaseC::GetNumInstances();

cachedDBData.reset();

ATMS::pEnumConverter = NULL;

// Get the count if base objects created by the DBLib

numLeaked = CommonBaseC::GetNumInstances();

configurationData.reset();

if( reporter )

{

delete reporter;

reporter = NULL;

ATMS::pReporter = NULL;

}

// Release COM

CoUninitialize();

}

catch(...)

{

// Error something threw something something dark side

std::wcout << "Error - Unhandled Exception";

return 1;

}

*/

int * p = new int(6);

return 0;

}

//------------------------

//DevTest_StatusClient.bat

inspxe-cl -collect mi3 -module-filter-mode=include -module-filter=DevTest_StatusClient.exe,CommonLibd.dll -- DevTest_StatusClient.exe

//-------------------------
//DevTest_StatusClient02.bat
inspxe-cl -collect mi3 -module-filter-mode=include -module-filter=DevTest_StatusClient.exe -- DevTest_StatusClient.exe

Umm, you've actually just allocated 4 * 1024 ints, each being 4 bytes on 32 bit Windows = 16KB. I really don't get your use of the sizeof operator there. You are allocating a quanitity of ints, not bytes.

Anyway, it doesn't matter if I allocate 1 or 5000, I get the same result.