debug实战：COM组件GetToSTA导致高内存+GC被阻塞
最近花了好几周解决一个WPF高内存的问题，问题的表象是内存不断增加、未被回收，根源是GC的FinalizeThread被阻塞，导致整个GC挂掉。从以下几步来分析这个问题：
1.用ANTS Memory Profiler去掉强引用
既然是高内存，肯定要先从内存着手。这里必须要赞一下ANTS的这个工具，图形化做的非常好，一目了然，个人觉得比SciTech的.net memory profiler好用。找个基准点take一个SnapShot，打开关闭窗口后再take一个snapshot，比较2个快照里多出了哪些对象，或者窗口对象被什么强引用了导致未被释放，都很清楚。一般来说是自己代码的问题，但也有第三方组件的坑，比如：
- DevExpress.Data.DelayedExecutionExtension里有static的Dictionary，会持有很多控件的强引用，需要在窗口Close时调用RemoveDelayedExecute()
- TypeDescriptor相关字样的一堆类（包括DPCustomTypeDescriptor、DependencyPropertyDescriptor、DependencyObjectProvider等），都通过DependencyObject._effectiveValues持有对窗口等控件的强引用，需要在窗口Close时调用TypeDescriptor.Refresh(object)
注：不查不知道，这个TypeDescriptor还大有来头，不仅管理着所有.net object的metadata，还可以动态修改这些metadata，这对于封装一些代理类、提供Transparent功能的场景应该很有用。详情见这篇博客TypeDescriptor
2.当去掉所有强引用后，大量对象堆积在FinalizeQueue上
在ANTS里看到，所有希望回收的对象，都堆积在FinalizeQueue上，即使内存飙到1G也无法回收。手动调GC强制回收，阻塞在WaitForPendingFinalizers()上一直无法返回。
GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();这时就只能抓dump用windbg分析到底是哪里卡住了。
3.抓dump分析线程堆栈
用ProcDump -ma [ProcessName]抓dump，分析如下：
0:000> .loadby sos clr
0:000> !threads
ThreadCount: 63
UnstartedThread: 0
BackgroundThread: 34
PendingThread: 0
DeadThread: 28
Hosted Runtime: no
Lock
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
0 1 1b80 00000000008c9cf0 26020 Preemptive 0000000000000000:0000000000000000 000000000087ce90 0 STA
2 2 ba8 00000000008d4790 2b220 Preemptive 0000000000000000:0000000000000000 000000000087ce90 0 MTA (Finalizer)
......
40 63 1748 0000000021ecc3d0 1029220 Preemptive 0000000000000000:0000000000000000 000000000087ce90 0 MTA (Threadpool Worker)
0:000> !syncblk
Index SyncBlock MonitorHeld Recursion Owning Thread Info SyncBlock Owner
-----------------------------
Total 173
CCW 5
RCW 5
ComClassFactory 0
Free 25
//并没有线程被锁住，看看2号Finalizer线程在干嘛
0:000> ~2kb
RetAddr : Args to Child : Call Site
000007fe`fcf210dc : 00000000`00000000 00000000`1b66f308 00000000`1b66ee60 00000000`1b66edd0 : ntdll!NtWaitForSingleObject+0xa
000007fe`fd2de68e : 00000000`1bf51bf0 00000000`00911fb0 00000000`00000000 00000000`0000044c : KERNELBASE!WaitForSingleObjectEx+0x79
000007fe`fd413700 : 00000000`008fd0b0 00000000`1bf51bf0 00000000`00000246 00000000`008fd0b0 : ole32!GetToSTA+0x8a
000007fe`fd41265b : 00000000`00000000 00000000`ffffffff 00000000`61a6d4cc 00000000`ffffffff : ole32!CRpcChannelBuffer::SwitchAptAndDispatchCall+0x13b
......
000007fe`e53b383c : 00000000`1bfd2380 00000000`1b66f9a8 00000000`00000000 000007fe`e5417ad3 : clr!CtxEntry::EnterContext+0x232
000007fe`e53b37e6 : 00000000`1b66f9a8 000007fe`e524307c 00000000`008d4790 00000000`1b66f9f0 : clr!RCW::EnterContext+0x3d
000007fe`e544319f : 000007fe`e5b055b0 00000000`008d4790 00000000`008d4790 00000000`00000000 : clr!SyncBlockCache::CleanupSyncBlocks+0xc2
000007fe`e536ab47 : 00000000`00000001 00000000`00000001 00000000`008d4790 00000000`00000000 : clr!Thread::DoExtraWorkForFinalizer+0xdc
000007fe`e52b458c : 0030002e`00340076 00000000`1b66fcc0 00000000`00390031 00000000`00001000 : clr!WKS::GCHeap::FinalizerThreadWorker+0x109
000007fe`e52b451a : 00000000`1b66fcc0 00000000`00000000 0000cd2d`f0a20ef6 000007fe`e53ff57a : clr!Frame::Pop+0x50
...
000007fe`e5391d90 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`0000001e : clr!ManagedThreadBase_NoADTransition+0x3f
000007fe`e53133de : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : clr!WKS::GCHeap::FinalizerThreadStart+0xb4
00000000`76fa59ed : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : clr!Thread::intermediateThreadProc+0x7d
00000000`770dc541 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d
//强烈建议关注一下GetToSTA，这个方法是COM组件引起GC阻塞的典型特征。原因是STA的COM组件必须在创建它的线程上被回收，所以FinalizerThread想GetToSTA线程去执行回收的代码。但它想GetTo的是哪个线程？那个线程又因为什么阻塞了呢？
000007fe`fd413700 : 00000000`008fd0b0 00000000`1bf51bf0 00000000`00000246 00000000`008fd0b0 : ole32!GetToSTA+0x8a
//首先用|查看进程ID
0:000> |
. 0 id: 3b8c examine name: E:\...\Process.exe
//然后在这个方法的参数列表上，依次执行dd并查找进程ID：3b8c，进程ID旁边就是它要去的线程ID，我是在第二个参数里找到的。
0:000> dd 1bf51bf0
00000000`1bf51bf0 fd4283e0 000007fe fd450628 000007fe
00000000`1bf51c00 00000000 00000000 00000001 0000102a
00000000`1bf51c10 00000000 00000000 0000044c 00000000
00000000`1bf51c20 00000000 00000000 00003400 1b803b8c
//最后一行的1b80 3b8c，后半段是进程ID、前半段是它要去STA线程。回上面一看，原来就是0号主线程。
0 1 1b80 00000000008c9cf0 26020 Preemptive 0000000000000000:0000000000000000 000000000087ce90 0 STA
//再看看0号主线程在干嘛？原来停在ConnectNamedPipe里，对应的.net代码是NamedPipeStreamServer.WaitForConnection()。这是个非托管的阻塞方法，只要等不到Connection，就会一直阻塞。
0:000> kb
RetAddr : Args to Child : Call Site
000007fe`fcf33c2f : 000007fe`e5311ed4 00000000`0027e428 00000000`0027e480 00000000`05d5cac8 : ntdll!NtFsControlFile+0xa
*** WARNING: Unable to verify checksum for System.Core.ni.dll
000007fe`e1ab8017 : 000007fe`e169adb8 00000000`00000000 00000000`00000000 00000000`05d5c7d8 : KERNELBASE!ConnectNamedPipe+0x6f
......
000007fe`e53a2a7e : 00000000`00000000 00000000`00000004 00000000`00000000 00000000`00000004 : clr!MethodDescCallSite::CallTargetWorker+0x2e2
000007fe`e53a31d6 : 00000000`00000004 00000000`00000000 00000000`00000000 00000000`03162eb8 : clr!RunMain+0x1e7
000007fe`e53a30d0 : 00000000`008f13b0 00000000`00000200 00000000`008f13b0 00000000`00000200 : clr!Assembly::ExecuteMainMethod+0xb6
000007fe`e53a2c46 : 00000000`0027f8c8 00000000`00bf0000 00000000`00000000 00000000`00000000 : clr!SystemDomain::ExecuteMainMethod+0x45e
000007fe`e53a2b9e : 00000000`00bf0000 00000000`0027fa20 00000000`00000000 000007fe`f6f441c0 : clr!ExecuteEXE+0x3f
000007fe`e53a3574 : ffffffff`ffffffff 00000000`00000000 00000000`00000000 00000000`00000000 : clr!CorExeMainInternal+0xae
000007fe`f6ee77ad : 00000000`00000000 000007fe`00000091 00000000`00000000 00000000`0027f988 : clr!CorExeMain+0x14
000007fe`f6fa5b21 : 00000000`00000000 000007fe`e53a3560 00000000`00000000 00000000`00000000 : mscoreei!CorExeMain+0xe0
00000000`76fa59ed : 000007fe`f6ee0000 00000000`00000000 00000000`00000000 00000000`00000000 : mscoree!CorExeMain_Exported+0x57
00000000`770dc541 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d怪不得FinalizerThread会挂掉，因为它要释放COM组件，所以要进到创建COM组件的STA线程，而这个STA线程又在无限期的等待Connection，所以就挂掉了。GC都挂了，永远不执行垃圾回收，当然会高内存。另：GetToSTA的手法太妖了，这么hack的方法我当然想不出来，请参见gcHang0、gcHang1、gcHang2、gcHang3
4.解决方案
- 把创建COM的线程改为MTA，因为主线程必须是STA的，所以只能新建一个MTA的线程来干这个事儿了。
- 如果非得在STA的线程里干这事儿，那就不能使用非托管的阻塞方法，比如WaitForConnection，而要使用托管的阻塞方法，比如WaitHandle.WaitOne, WaitAny, WaitAll, Monitor.Enter, Monitor.Block, Thread.Join, GC.WaitForPendingFinalizers这些都是，这些方法在阻塞线程的同时，还能正确的pump messages。这些托管的阻塞方法，配合对应的Begin/End异步方法，就能响应各种消息了。