2014-09-04 99 views
1

我看到下面的終止程序線程調用棧。在finalizer的頂部調用WaitForSingleObject是否正常?無論如何,我可以確定它是否陷入僵局或等待很長時間?是終止程序終止符的指示

0:009> k 
Child-SP   RetAddr   Call Site 
00000000`0a56e5c8 000007fe`fd5010dc ntdll!NtWaitForSingleObject+0xa 
00000000`0a56e5d0 000007fe`fdfabeb5 KERNELBASE!WaitForSingleObjectEx+0x79 
00000000`0a56e670 000007fe`fe04a576 rpcrt4!UTIL_GetOverlappedResultEx+0x45 
00000000`0a56e6b0 000007fe`fdfaf0dd rpcrt4!WS_SyncRecv+0xf6 
00000000`0a56e720 000007fe`fdfe7a29 rpcrt4!OSF_CCONNECTION::TransSendReceive+0x18d 
00000000`0a56e780 000007fe`fdfa7f61 rpcrt4!OSF_CCONNECTION::SendBindPacket+0xa5c 
00000000`0a56e930 000007fe`fdfa8e27 rpcrt4!OSF_CCONNECTION::ActuallyDoBinding+0xc1 
00000000`0a56e9d0 000007fe`fdfa8bb6 rpcrt4!OSF_CCONNECTION::OpenConnectionAndBind+0x207 
00000000`0a56ea90 000007fe`fdfa8acd rpcrt4!OSF_CCALL::BindToServer+0xc6 
00000000`0a56eb40 000007fe`fdfadaeb rpcrt4!OSF_BINDING_HANDLE::InitCCallWithAssociation+0xa5 
00000000`0a56eba0 000007fe`fdfad9d0 rpcrt4!OSF_BINDING_HANDLE::AllocateCCall+0x102 
00000000`0a56ecd0 000007fe`fdfc74eb rpcrt4!OSF_BINDING_HANDLE::NegotiateTransferSyntax+0x30 
00000000`0a56ed20 000007fe`ff462271 rpcrt4!I_RpcNegotiateTransferSyntax+0x9f 
00000000`0a56edb0 000007fe`ff45d185 ole32!CRpcChannelBuffer::NegotiateSyntax+0x69 
00000000`0a56ee20 000007fe`fe05ba22 ole32!NdrExtNegotiateTransferSyntax+0xe5 
00000000`0a56ee60 000007fe`fe05cbbb rpcrt4!Ndr64pClientSetupTransferSyntax+0x453 
00000000`0a56eec0 000007fe`ff4621d0 rpcrt4!NdrpClientCall3+0xcb 
00000000`0a56f180 000007fe`ff31d8a2 ole32!ObjectStublessClient+0x11d 
00000000`0a56f510 000007fe`ff321bb3 ole32!ObjectStubless+0x42 
00000000`0a56f560 000007fe`ff321b22 ole32!RemoteReleaseRifRefHelper+0x57 
00000000`0a56f5b0 000007fe`ff3217eb ole32!RemoteReleaseRifRef+0xca 
00000000`0a56f620 000007fe`ff321417 ole32!CStdMarshal::DisconnectCliIPIDs+0x4c2 
00000000`0a56f720 000007fe`ff3194fa ole32!CStdMarshal::Disconnect+0x40c 
00000000`0a56f780 000007fe`ff319428 ole32!CStdIdentity::~CStdIdentity+0xa6 [d:\w7rtm\com\ole32\com\dcomrem\stdid.cxx @ 312] 
00000000`0a56f7b0 000007fe`ff319b49 ole32!CStdIdentity::`scalar deleting destructor'+0x14 
00000000`0a56f7e0 000007fe`f2a79f94 ole32!CStdIdentity::CInternalUnk::Release+0xdc [d:\w7rtm\com\ole32\com\dcomrem\stdid.cxx @ 767] 
00000000`0a56f810 000007fe`f2ba8bea clr!SafeReleasePreemp+0x74 
00000000`0a56f860 000007fe`f2ba8acc clr!RCW::ReleaseAllInterfaces+0xda 
00000000`0a56f8b0 000007fe`f2ba8c14 clr!RCW::ReleaseAllInterfacesCallBack+0x54 
00000000`0a56f930 000007fe`f2ba937e clr!RCW::Cleanup+0x25 
00000000`0a56f980 000007fe`f2ba9214 clr!RCWCleanupList::ReleaseRCWListRaw+0x16 
00000000`0a56f9b0 000007fe`f2bb005a clr!RCWCleanupList::ReleaseRCWListInCorrectCtx+0x94 
00000000`0a56f9f0 000007fe`f2be326e clr!RCWCleanupList::CleanupAllWrappers+0xe5 
00000000`0a56fa70 000007fe`f2be319f clr!SyncBlockCache::CleanupSyncBlocks+0xc2 
00000000`0a56fae0 000007fe`f2be47c7 clr!Thread::DoExtraWorkForFinalizer+0xdc 
00000000`0a56fb10 000007fe`f2a5458c clr!SVR::GCHeap::FinalizerThreadWorker+0x78 
00000000`0a56fb50 000007fe`f2a5451a clr!Frame::Pop+0x50 
00000000`0a56fb90 000007fe`f2a54491 clr!COMCustomAttribute::PopSecurityContextFrame+0x192 
00000000`0a56fc90 000007fe`f2b31bfe clr!COMCustomAttribute::PopSecurityContextFrame+0xbd 
00000000`0a56fd20 000007fe`f2b45020 clr!ManagedThreadBase_NoADTransition+0x3f 
00000000`0a56fd80 000007fe`f2ab33de clr!SVR::GCHeap::FinalizerThreadStart+0xb4 
00000000`0a56fdc0 00000000`772459ed clr!Thread::intermediateThreadProc+0x7d 
00000000`0a56fe80 00000000`7747c541 kernel32!BaseThreadInitThunk+0xd 
00000000`0a56feb0 00000000`00000000 ntdll!RtlUserThreadStart+0x1d 

0:009> !CLRStack 
OS Thread Id: 0x1338 (6) 
     Child SP    IP Call Site 
000000000b67fcd8 00000000774a12fa [DebuggerU2MCatchHandlerFrame: 000000000b67fcd8] 
+0

得分1爲心理調試:) – 2014-09-04 19:39:57

+1

不知道我是否按照您的評論,但來自你的任何東西總是很好:) – 2014-09-04 19:42:27

+1

它試圖通過TCP通道發佈COM對象。 COM對象可能駐留在不同的機器上。這確實需要心理調試才能弄清楚。你是否反覆看到這一點,或者這是一次性的?如果這只是一次性的事情,那麼它可能只是緩慢而沒有陷入僵局。 – 2014-09-04 20:13:35

回答

1

這是一個終結器工作者,它被RPC響應阻塞。在這種情況下,如果線程沒有等待超過幾毫秒(取決於COM服務器響應請求的時間長短),這是正常的。但是,如果我們等待的時間更長,那麼您可能需要調查響應數據包的情況。

有一個在用戶模式下沒有辦法理解什麼是線程的蜱計數可能需要使用livekd運​​行的系統上,如果這個問題重新可生產檢查同一線程

0

正是這種跡象的終結者封鎖。一個非常簡單的例子,如果你使用COM在Excel和C#之間進行交互。 您有一個Excel模塊正在成爲C#的成員變量,然後可能會出現問題,因爲該模塊的控制權在GC手中,但Excel將等待它由C#發佈。 簡單的方法是在清除非託管代碼之前清除C#組件中的任何非託管代碼。