I’ve inherited some terrible MSXML parsing code (which sadly I don’t have time to rewrite). This code is full of COM interface/BSTR leaks where the original authors have either misused manual COM reference counting (which always seems to end in tears) or where they’ve used COM smart pointers but used them wrongly such that leaks have occurred.
I’ve now fixed many of the leaks in the code but I’m still finding that msxml3.dll isn’t unloaded when I call CoUninitialize() (which it should be if all the interfaces have gone) and more memory is being used than I expect after this code has run.
I’m now reaching the limit of what I can spot by hand, and I’m looking round for a debugging solution that can identify these kinds of leaks. I’ve used umdh in the past with good effect to spot conventional leaks but this doesn’t seem terribly helpful with COM leaks. Can anyone recommend a good approach?
Try BoundsChecker (a Micro Focus product). If you activate the “COM Object Tracking” feature, it will show you COM interface leaks. It works on both X86 and X64 applications. That said, your mileage may vary: I am working on cleaning that code right this moment (which is what led me to your question through Google), and our next release should be better. This particular code hasn’t been touched in many years.
With regards to SysAlloc leaks, that is a difficult area because of how the IMalloc class caches released memory, not really releasing it. I am still working on that area as time and interruptions permit.
Disclosure (if it isn’t obvious already): I work for Micro Focus, and specifically on BoundsChecker.