I have two fundamental questions regarding umdh:
How can it help me find leaks if all it does is report allocations, not deallocations? In the diff result I get lots of new allocations, but there's no report on which were deallocated and which weren't (thus causing a leak).
The diff report is ordered by decreasing allocation size. At the bottom of the report there are a few allocations which are a negative number, and the number of the allocations is 0. What does that mean?
UMDH (or actually: Windows due to a GFlag setting) will store the callstack at the time memory is allocated for an object. If that memory is freed, the callstack is lost as well. But that's ok, because it is freed and you don't have a leak in that case.
So the remaining items (everything you see) are allocations which are (potentially) causing the leak. For all those allocations you know where the object is created (from the callstack) and it's your task to find out where it should be freed (e.g. by code review).
I'm not exactly sure about this, but consider a long-living object which existed before you took the first UMDH snapshot. If this is freed later on, it will appear as negative memory. In such a case you probably don't have a callstack as well (as explained in 1.) and it's just an information.
It could indicate that you should start making UMDH snapshots earlier, but usually it's also ok to ignore those if the size does not match the objects you're looking for.
