UMDH
UMDH是基于trace或者dump想法的工具。在使用UMDH之前首先要使用GFlags enable stack trace。然后在leak之前和leak之后分别对stack trace做dump，然后对前后的trace做比较。下面是比较后结果的一个示例：
对各个数字的含义使用红字标出
+ 25be880 [两次的数值差，表明在两次dump之间同样的call stack 又分配了多少内存]( 25ce890[第二次stace中分配的总byte数] – 10010[第一次strac中分配的总byte数]) 1c allocs BackTraceB30BBE0
+ 1b [两个dump之间的调用次数]( 1c [第二次dump时trace中该call stack 被调用的次数]- 1[第一次dump时trace中该call stack调用的次数]) BackTraceB30BBE0 allocations
ntdll!RtlAllocateHeap+00000274 (d:\w7rtm\minkernel\ntos\rtl\heap.c, 1714)
npctrl!CWindowsServices::OSMemoryAllocate+00000018 (f:\dd\xcp\win\dll\xcpwin.cpp, 2741)
agcore!CLocalMemorySurface::Create+000000EA (f:\dd\xcp\core\dll\xcpcore.cpp, 13346)
agcore!CPngLibDecoder::Decode+00000314 (f:\dd\xcp\core\codec\png\pngdecoder.cpp, 281)
agcore!CBitmapCacheManager::Decode+0000004C (f:\dd\xcp\core\elements\bitmapcache.cpp, 155)
agcore!CBitmapCacheManager::DecodeAndAdd+0000006C (f:\dd\xcp\core\elements\bitmapcache.cpp, 209)
agcore!CBitmapImage::GotResponse+0000019D (f:\dd\xcp\core\elements\imagesource.cpp, 683)
npctrl!CWindowsDownloadRequest::FireGotResponse+000000AF (f:\dd\xcp\win\dll\windwnreq.cpp, 1175)
npctrl!CWindowsDownloadRequest::OnStopBinding+00000094 (f:\dd\xcp\win\dll\windwnreq.cpp, 868)
urlmon!CBSCHolder::OnStopBinding+0000004B (d:\win7_gdr\inetcore\urlmon\mon\mpxbsc.cxx, 996)
urlmon!CBinding::CallOnStopBinding+00000045 (d:\win7_gdr\inetcore\urlmon\trans\cbinding.cxx, 4241)
urlmon!CBinding::OnTransNotification+00000451 (d:\win7_gdr\inetcore\urlmon\trans\cbinding.cxx, 2292)
urlmon!CBinding::ReportData+00000080 (d:\win7_gdr\inetcore\urlmon\trans\cbinding.cxx, 4744)
urlmon!COInetProt::ReportData+00000070 (d:\win7_gdr\inetcore\urlmon\trans\prothndl.cxx, 1627)
urlmon!CTransaction::DispatchReport+0000037B (d:\win7_gdr\inetcore\urlmon\trans\transact.cxx, 2871)
urlmon!CTransaction::DispatchPacket+00000031 (d:\win7_gdr\inetcore\urlmon\trans\transact.cxx, 2980)
urlmon!CTransaction::OnINetCallback+00000092 (d:\win7_gdr\inetcore\urlmon\trans\transact.cxx, 3043)
urlmon!CTransaction::ReportData+00000161 (d:\win7_gdr\inetcore\urlmon\trans\transact.cxx, 509)
urlmon!CINet::ReportDataToProtocolSink+000000B4 (d:\win7_gdr\inetcore\urlmon\iapp\cnet.cxx, 2307)
urlmon!CINetFile::INetAsyncOpen+00000216 (d:\win7_gdr\inetcore\urlmon\iapp\cnetsimp.cxx, 303)
urlmon!CINet::INetAsyncStart+0000001A (d:\win7_gdr\inetcore\urlmon\iapp\cnet.cxx, 2811)
urlmon!CINet::StartEx+0000001C (d:\win7_gdr\inetcore\urlmon\iapp\cnet.cxx, 986)
urlmon!COInetProt::StartEx+000000C3 (d:\win7_gdr\inetcore\urlmon\trans\prothndl.cxx, 408)
urlmon!CTransaction::StartEx+000003E2 (d:\win7_gdr\inetcore\urlmon\trans\transact.cxx, 4044)
urlmon!CBinding::StartBinding+00000602 (d:\win7_gdr\inetcore\urlmon\trans\cbinding.cxx, 2080)
urlmon!CUrlMon::StartBinding+00000169 (d:\win7_gdr\inetcore\urlmon\trans\urlmon.cxx, 1045)
urlmon!CUrlMon::BindToStorage+00000090 (d:\win7_gdr\inetcore\urlmon\trans\urlmon.cxx, 920)
npctrl!CWindowsDownloadRequest::_Download+00000433 (f:\dd\xcp\win\dll\windwnreq.cpp, 1910)
npctrl!CWindowsDownloadRequest::InitiateRequest+00000617 (f:\dd\xcp\win\dll\windwnreq.cpp, 1688)
npctrl!CXcpBrowserHost::ProcessAsyncDownloadRequest_BrowserImpl+00000297 (f:\dd\xcp\win\dll\winbrowserhost.cpp, 2221)
npctrl!CXcpBrowserHost::ProcessAsyncDownloadRequest+000000FA (f:\dd\xcp\win\dll\winbrowserhost.cpp, 2089)
npctrl!CDownloadRequest::Download+0000004B (f:\dd\xcp\control\common\shared\downloadrequest.cpp, 234)
Reference： http://support.microsoft.com/kb/268343
LeakDiag
LeakDiag 是基于instrument思想的memory leak detect 工具。Using Microsoft's Detours technology, LeakDiag intercepts calls to specified memory allocators and tracks the various call stacks. It reports on the memory that has been allocated but not yet freed. This information allows a person troubleshooting a memory leak problem to see exactly what components made the allocations. With proper debug symbols, even the line of code that requested the allocations can be seen.
LeakDiag可以拦截特定的内存分配操作，并且跟踪各种call stack。目前它可以拦截如下几种内存分配操作：
- Virtual Allocator (VirtualAlloc)
- NT Heap Allocator (HeapAlloc)[DEFAULT]
- MPHeap Allocator (MPHeap)
- COM Allocator (CoTask)
- COM Private Allocator (PrivateMemAlloc)
- C Runtime Allocator (msvcrt new)
因为各个内存分配的层次和所在组件不同，所以在选择对哪种分配操作进行拦截之前，可以先根据上一篇文章对leak的原因有一定的分析，然后选择某个Allocator，使得分析更有效。