我遇到了ATL COM服务器的问题，该服务器随着时间的推移会占用大量内存。我怀疑是内存泄漏，但我无法查明原因。该服务在48小时压力测试过程中缓慢增加记忆。
这是我在1小时后通过分析过程在WinDBG中收集的内容。我在这里放置一些占据大部分内存的对象。
size #blocks total ( %) (percent of total busy bytes)
190 6c3 - a90b0 (32.86)
30 1507 - 3f150 (12.26)
!heap -flt s 190
!heap -p -a 0000000002ae0ee0
address 0000000002ae0ee0 found in
_HEAP @ 1a40000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0000000002ae0eb0 001c 0000 [00] 0000000002ae0ee0 00190 - (busy)
combase!CStdIdentity::`vftable'
7ffd1aa71be7 ntdll!RtlAllocateHeap+0x000000000006fb17
7ffd18676158 combase!CIDObject::GetOrCreateStdID+0x0000000000000128
7ffd1867a788 combase!CDestObjectWrapper::MarshalInterface+0x00000000000006ca
7ffd186795c2 combase!CoMarshalInterface+0x00000000000001a2
7ffd1868145f combase!MarshalHelperMulti+0x000000000000006f
7ffd1868139f combase!GetInstanceHelperMulti+0x0000000000000083
7ffd18681129 combase!CObjServer::CreateInstance+0x0000000000000467
7ffd18b02385 RPCRT4!Invoke+0x0000000000000065
7ffd18b0ae16 RPCRT4!NdrStubCall2+0x000000000000038b
7ffd18b170eb RPCRT4!NdrStubCall3+0x000000000000014a
7ffd187a05ff combase!CStdStubBuffer_Invoke+0x0000000000000067
7ffd187a04d9 combase!SyncStubInvoke+0x0000000000000306
7ffd18633fc9 combase!CCtxComChnl::ContextInvoke+0x0000000000000279
7ffd187a13ff combase!AppInvoke+0x000000000000018f
7ffd187a0e9b combase!ComInvokeWithLockAndIPID+0x0000000000000661
7ffd187a184e combase!ThreadInvoke+0x0000000000000481
7ffd18b02614 RPCRT4!DispatchToStubInCNoAvrf+0x0000000000000014
7ffd18b02517 RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x0000000000000177
7ffd18b16ebf RPCRT4!LRPC_SCALL::DispatchRequest+0x0000000000000531
7ffd18b02cc1 RPCRT4!LRPC_SCALL::HandleRequest+0x0000000000000201
7ffd18b02a97 RPCRT4!LRPC_SASSOCIATION::HandleRequest+0x0000000000000237
7ffd18b01d04 RPCRT4!LRPC_ADDRESS::ProcessIO+0x000000000000036d
7ffd18b01afe RPCRT4!LrpcIoComplete+0x00000000000000ae
7ffd1a9fd394 ntdll!TppAlpcpExecuteCallback+0x0000000000000204
7ffd1a9fb96d ntdll!TppWorkerThread+0x00000000000003ad
7ffd184f15bd KERNEL32!BaseThreadInitThunk+0x000000000000000d
7ffd1aa343d1 ntdll!RtlUserThreadStart+0x000000000000001d
!heap -flt s 30
!heap -p -a 0000000002af5960
address 0000000002af5960 found in
_HEAP @ 1a40000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0000000002af5930 0006 0000 [00] 0000000002af5960 00030 - (busy)
7ffd1aa71be7 ntdll!RtlAllocateHeap+0x000000000006fb17
7ffd1a9e0056 ntdll!RtlpAddDebugInfoToCriticalSection+0x0000000000000012
7ffd1aa79db4 ntdll!RtlInitializeCriticalSectionAndSpinCount+0x0000000000055dd4
7ffd18674b24 combase!CStdIdentity::CStdIdentity+0x00000000000002d4
7ffd1867618d combase!CIDObject::GetOrCreateStdID+0x000000000000015d
7ffd1867a788 combase!CDestObjectWrapper::MarshalInterface+0x00000000000006ca
7ffd186795c2 combase!CoMarshalInterface+0x00000000000001a2
7ffd1868145f combase!MarshalHelperMulti+0x000000000000006f
7ffd1868139f combase!GetInstanceHelperMulti+0x0000000000000083
7ffd18681129 combase!CObjServer::CreateInstance+0x0000000000000467
7ffd18b02385 RPCRT4!Invoke+0x0000000000000065
7ffd18b0ae16 RPCRT4!NdrStubCall2+0x000000000000038b
7ffd18b170eb RPCRT4!NdrStubCall3+0x000000000000014a
7ffd187a05ff combase!CStdStubBuffer_Invoke+0x0000000000000067
7ffd187a04d9 combase!SyncStubInvoke+0x0000000000000306
7ffd18633fc9 combase!CCtxComChnl::ContextInvoke+0x0000000000000279
7ffd187a13ff combase!AppInvoke+0x000000000000018f
7ffd187a0e9b combase!ComInvokeWithLockAndIPID+0x0000000000000661
7ffd187a184e combase!ThreadInvoke+0x0000000000000481
7ffd18b02614 RPCRT4!DispatchToStubInCNoAvrf+0x0000000000000014
7ffd18b02517 RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x0000000000000177
7ffd18b16ebf RPCRT4!LRPC_SCALL::DispatchRequest+0x0000000000000531
7ffd18b02cc1 RPCRT4!LRPC_SCALL::HandleRequest+0x0000000000000201
7ffd18b02a97 RPCRT4!LRPC_SASSOCIATION::HandleRequest+0x0000000000000237
7ffd18b01d04 RPCRT4!LRPC_ADDRESS::ProcessIO+0x000000000000036d
7ffd18b01afe RPCRT4!LrpcIoComplete+0x00000000000000ae
7ffd1a9fd394 ntdll!TppAlpcpExecuteCallback+0x0000000000000204
7ffd1a9fb96d ntdll!TppWorkerThread+0x00000000000003ad
7ffd184f15bd KERNEL32!BaseThreadInitThunk+0x000000000000000d
7ffd1aa343d1 ntdll!RtlUserThreadStart+0x000000000000001d
其他对象：
size #blocks total ( %) (percent of total busy bytes)
48 6c2 - 1e690 (91.91)
1000 1 - 1000 (3.02)
!heap -flt s 48
!heap -p -a 0000000002ab8000
address 0000000002ab8000 found in
_HEAP @ 1a40000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
0000000002ab7fd0 0007 0000 [00] 0000000002ab8000 00048 - (busy)
combase!g_ForwardingVtbl
7ffd1aa71be7 ntdll!RtlAllocateHeap+0x000000000006fb17
7ffd18674115 combase!CreateStubFromTypeInfo+0x0000000000000061
7ffd18b58f63 RPCRT4!CreateStubFromTypeInfo+0x0000000000000043
7ffd1908dcf8 OLEAUT32!CUnivStubWrapper::Invoke+0x0000000000000098
7ffd187a04d9 combase!SyncStubInvoke+0x0000000000000306
7ffd18633fc9 combase!CCtxComChnl::ContextInvoke+0x0000000000000279
7ffd187a13ff combase!AppInvoke+0x000000000000018f
7ffd187a0e9b combase!ComInvokeWithLockAndIPID+0x0000000000000661
7ffd187a184e combase!ThreadInvoke+0x0000000000000481
7ffd18b02614 RPCRT4!DispatchToStubInCNoAvrf+0x0000000000000014
7ffd18b02517 RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x0000000000000177
7ffd18b16ebf RPCRT4!LRPC_SCALL::DispatchRequest+0x0000000000000531
7ffd18b02cc1 RPCRT4!LRPC_SCALL::HandleRequest+0x0000000000000201
7ffd18b02a97 RPCRT4!LRPC_SASSOCIATION::HandleRequest+0x0000000000000237
7ffd18b01d04 RPCRT4!LRPC_ADDRESS::ProcessIO+0x000000000000036d
7ffd18b01afe RPCRT4!LrpcIoComplete+0x00000000000000ae
7ffd1a9fd394 ntdll!TppAlpcpExecuteCallback+0x0000000000000204
7ffd1a9fb96d ntdll!TppWorkerThread+0x00000000000003ad
7ffd184f15bd KERNEL32!BaseThreadInitThunk+0x000000000000000d
7ffd1aa343d1 ntdll!RtlUserThreadStart+0x000000000000001d
!heap -p -a 000000000282f280
address 000000000282f280 found in
_HEAP @ 20a0000
HEAP_ENTRY Size Prev Flags UserPtr UserSize - state
000000000282f250 0007 0000 [00] 000000000282f280 00048 - (busy)
ccprovsp!ATL::CComObject<MyCOM>::`vftable'
7ffd1aa71be7 ntdll!RtlAllocateHeap+0x000000000006fb17
140028c87 ccprovsp!malloc+0x0000000000000067
14002815e ccprovsp!operator new+0x000000000000000e
14000280b ccprovsp!ATL::CComCreator<ATL::CComObject<MyCOM> >::CreateInstance+0x000000000000005b
14000239c ccprovsp!ATL::CComCreator2<ATL::CComCreator<ATL::CComObject<MyCOM> >,ATL::CComFailCreator<-2147221232> >::CreateInstance+0x000000000000002c
1400085a7 ccprovsp!ATL::CComClassFactory::CreateInstance+0x0000000000000077
7ffd1868134c combase!GetInstanceHelperMulti+0x0000000000000034
7ffd18681129 combase!CObjServer::CreateInstance+0x0000000000000467
7ffd18b02385 RPCRT4!Invoke+0x0000000000000065
7ffd18b0ae16 RPCRT4!NdrStubCall2+0x000000000000038b
7ffd18b170eb RPCRT4!NdrStubCall3+0x000000000000014a
7ffd187a05ff combase!CStdStubBuffer_Invoke+0x0000000000000067
7ffd187a04d9 combase!SyncStubInvoke+0x0000000000000306
7ffd18633fc9 combase!CCtxComChnl::ContextInvoke+0x0000000000000279
7ffd187a13ff combase!AppInvoke+0x000000000000018f
7ffd187a0e9b combase!ComInvokeWithLockAndIPID+0x0000000000000661
7ffd187a184e combase!ThreadInvoke+0x0000000000000481
7ffd18b02614 RPCRT4!DispatchToStubInCNoAvrf+0x0000000000000014
7ffd18b02517 RPCRT4!RPC_INTERFACE::DispatchToStubWorker+0x0000000000000177
7ffd18b16ebf RPCRT4!LRPC_SCALL::DispatchRequest+0x0000000000000531
7ffd18b02cc1 RPCRT4!LRPC_SCALL::HandleRequest+0x0000000000000201
7ffd18b02a97 RPCRT4!LRPC_SASSOCIATION::HandleRequest+0x0000000000000237
7ffd18b01d04 RPCRT4!LRPC_ADDRESS::ProcessIO+0x000000000000036d
7ffd18b01afe RPCRT4!LrpcIoComplete+0x00000000000000ae
7ffd1a9fd394 ntdll!TppAlpcpExecuteCallback+0x0000000000000204
7ffd1a9fb96d ntdll!TppWorkerThread+0x00000000000003ad
7ffd184f15bd KERNEL32!BaseThreadInitThunk+0x000000000000000d
7ffd1aa343d1 ntdll!RtlUserThreadStart+0x000000000000001d
关于我接下来应该做什么的暗示？
答案 0 :(得分：1)
首先，您似乎已正确设置GFlags以跟踪内存分配。这是一件好事，肯定有助于找到问题所在。但是，您发布的对象毫无意义，因为我们无法判断它们当前是否应该使用。
在WinDbg中进行分析非常困难，需要大量的手动工作。幸运的是，UMDH (MSDN)会对这种情况有所帮助。
如何继续
由于您可以在相对较短的时间内重现问题（1小时内600 kB即可），请执行此操作。创建一个场景，您可以反复在应用程序中达到相同的状态，并且（在您看来）应该再次释放所有内存。超过一小时，始终在达到该状态时创建UMDH快照。稍后，分析日志文件（此方法称为＆＃34;模式2和＃34;）。
UMDH将按调用堆栈对所有内存分配进行排序。如果您设法绘制一段时间内的分配图表，例如在Excel中，您可能会看到一条正在上升的行。这可能是罪魁祸首。您可以尝试使用HeapProfiler生成这样的图表（之前我从未使用过该图表，因为我有自己的工具来创建图表，遗憾的是此时尚未准备好发布）。
当您知道丢失的对象类型时，您知道它的分配位置（来自调用堆栈）。然后执行代码审查并找到应该发布的位置。试着弄清楚为什么它没有被释放（这是非常困难的部分）。
进一步阅读
Tarik Soulami的书Inside Windows Debugging (Amazaon)在第8章中介绍了UMDH。
您可能还想阅读或收听一些在线教程，例如： Using UMDH to Find a User-Mode Memory Leak或Finding Memory Leaks with UMDH。