我们有一个.NET后台处理应用程序(控制台应用程序),它执行一些任意工作负载(基本上内部用户提供实现"执行"接口的.NET DLL).然后,后台处理应用程序通过反射加载dll并执行它.
其中一个提供的DLL显然有一个COM对象,它没有正确处理(可能).
由于处理时间很长,并且我们在主线程上创建了COM对象而没有正确处理,这会导致终结器线程被阻塞,这会导致进程累积大量未释放的句柄(它可能会上升)到几十万)
我已经尝试使用WinDbg调试该进程的转储,我清楚地看到终结器线程在COM调用的主线程上被阻止.
首先我们看一下终结器线程中的非托管堆栈(我假设尝试与另一个线程通信以完成COM对象):
0:002> kb
# ChildEBP RetAddr Args to Child
00 0372eec0 74a92cc7 00000968 00000000 00000000 ntdll!NtWaitForSingleObject+0xc
01 0372ef34 74a92c02 00000968 ffffffff 00000000 KERNELBASE!WaitForSingleObjectEx+0x99
02 0372ef48 74dd9839 00000968 ffffffff 010846e4 KERNELBASE!WaitForSingleObject+0x12
03 (Inline) -------- -------- -------- -------- combase!MTAThreadWaitForCall+0x43 [d:\blue\com\combase\dcomrem\channelb.cxx @ 5657]
04 0372ef78 74e7d524 01083ef0 0111a198 0372f1e4 combase!MTAThreadDispatchCrossApartmentCall+0x1ed [d:\blue\com\combase\dcomrem\chancont.cxx @ 193]
05 (Inline) -------- -------- -------- -------- combase!CRpcChannelBuffer::SwitchAptAndDispatchCall+0x33a2 [d:\blue\com\combase\dcomrem\channelb.cxx @ 5052]
06 0372f0cc 74d5caea 010846e4 0372f1e4 0372f1ac combase!CRpcChannelBuffer::SendReceive2+0x62d [d:\blue\com\combase\dcomrem\channelb.cxx @ 4796]
07 (Inline) -------- -------- -------- …