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异步方法，就能响应各种消息了。

5.演示的Demo

最后用一个小Demo把问题重现了一遍，也把解决方案附在里面了，有兴趣的同学可以试一下。