使用C＃插件在COM應用程序中掛起

我遇到了一個問題，那就是我們的應用程序掛在客戶的機器上，而我現在一直在使用這些機器而沒有解決問題。這個問題從我們所看到的非常隨機地出現，儘管這可能不是真實的情況。客戶還報告說，當應用程序掛起時，CPU正在達到峯值。使用C＃插件在COM應用程序中掛起

問題是，我不知道應用程序在哪裏失敗（掛起）。我們還有一些用C＃編寫的插件作爲主COM應用程序的插件。

我已經成功地得到了客戶採取轉儲與ProcExp發生問題的機器上。但是，對於這個問題，我對WinDBG或MiniDump不是很熟悉。我運行了!analyze -v和!analyze -v -hang，它產生了一些輸出，包括下面的堆棧。對於我所能說的，似乎應用程序正在轉換到我們的C＃插件（CLR）之一，然後又回到COM，這應該是一個接口，返回到插件可用的主應用程序。但那又如何？是否有可能從這個堆棧中多說些什麼？

主要應用程序是用VB6編寫的，如果有問題的話。

0012da70 7e3693e9 7e3693a8 0012daf0 00000000 ntdll!KiFastSystemCallRet 
0012da9c 7e37a43b 0012daf0 00000000 0000000f user32!NtUserPeekMessage+0xc 
0012dac8 7348e6fd 0012daf0 00000000 0000000f user32!PeekMessageA+0xeb 
0012db1c 77532a9c 00d03774 00000000 00000000 msvbvm60!CMsgFilter::MessagePending+0x21f 
0012db60 77532a48 00000102 0012dbec 00000001 ole32!CCliModalLoop::HandlePendingMessage+0x40 
0012dba8 7751eda6 80010116 80010115 00000000 ole32!CCliModalLoop::HandleWakeForMsg+0x46 
0012dbbc 77547297 0012ddf0 00000001 0012dbe8 ole32!CCliModalLoop::BlockFn+0x8b 
0012dc30 0ae8a2fd 00000002 00000001 00000001 ole32!CoWaitForMultipleHandles+0xcf 
0012dc50 0ae8a264 00000000 00000001 00000001 mscorwks!NT5WaitRoutine+0x51 
0012dcbc 0ae8a1c8 00000001 0012ddf0 00000000 mscorwks!MsgWaitHelper+0xa5 
0012dcdc 0af3ccd0 00000001 0012ddf0 00000000 mscorwks!Thread::DoAppropriateAptStateWait+0x28 
0012dd60 0af3cd65 00000001 0012ddf0 00000000 mscorwks!Thread::DoAppropriateWaitWorker+0x13c 
0012ddb0 0ae8c026 00000001 0012ddf0 00000000 mscorwks!Thread::DoAppropriateWait+0x40 
0012de00 0ae90f4c 00000001 05ae5c80 0012de60 mscorwks!Thread::JoinEx+0x86 
0012de10 0b00ea40 00000001 00000001 5bdf0a2d mscorwks!Thread::Join+0x14 
0012de60 0af0b9a7 00000001 0012deb0 0af0ba10 mscorwks!RCWCleanupList::CleanupWrappersInCurrentCtxThread+0x15a 
0012de6c 0af0ba10 001df674 0012df10 5bdf0afd mscorwks!RCW::Initialize+0x78 
0012deb0 0af0b6a7 001df674 0012df10 5bdf0b6d mscorwks!RCW::CreateRCW+0x84 
0012df20 0af0b7b5 00000000 0012df5c 5bdf0b21 mscorwks!COMInterfaceMarshaler::CreateObjectRef+0x45 
0012df6c 0ae892a8 5bdf3065 0012e6c8 0012e6c8 mscorwks!COMInterfaceMarshaler::FindOrCreateObjectRef+0xac 
0012e428 0ae89444 001df658 11a11014 00000001 mscorwks!GetObjectRefFromComIP+0x1ec 
0012e448 0ae894ab 05b3b0a8 001df658 0e896204 mscorwks!UnmarshalObjectFromInterface+0x19 
0012e464 0af164d1 0012e6c8 0012e6ac 0af164c1 mscorwks!InterfaceMarshalerBase::ConvertSpaceNativeToCLR+0x30 
0012e470 0af164c1 0012e748 0012e738 5bdf32e1 mscorwks!DefaultMarshalOverrides<InterfaceMarshalerBase>::ReturnCLRFromNativeRetval+0xb 
0012e6ac 0aeb4bff 11741a76 0012e734 0012e74c mscorwks!RunML+0x9ac 
0012e780 11740172 05ae5c80 0012e7d4 501b6046 mscorwks!CLRToCOMWorker+0x25f 
... 
... Stack begins down here in our main COM application.

編輯1： 閱讀其他一些論壇帖子後，我已經有了一些想法。在我看來，懸掛是從.NET到COM的數據類型編組之後引入的。現在我已閱讀了有關another problem的信息，這似乎源於傳入COM方法的局部變量被垃圾收集的事實，因此VB6運行時間在處理釋放的內存時遇到了問題。那另一個帖子並不是這個問題，但它讓我思考。

在.NET代碼調用到COM，我們有這種類型的代碼

void SomeNETMethod(MyObject obj, bool doIt) { 
    string someString = obj.SomeString; 
    this.myComComponent.DoItInCOM(ref someString, ref doIt); // This is where it hangs. 
}

莫非ref bool以及直接從方法到方法傳遞的參數有什麼關係什麼？正如你所看到的，我跌跌撞撞在這裏暗...

來源

2012-01-24 lbergnehr

VB6和線程是水和火。當VB6主線程停止泵送消息循環時，看起來像是死鎖。你需要VB6調試器來找出它在做什麼。 –

即使我們的C＃插件不是多線程的@HansPassant可能會出現這些問題嗎？我能看到的唯一'其他'線程是GC線程，但我認爲這不是問題。 – lbergnehr

被調用的VB6代碼中是否有DoEvents？正如@HansPassant指出的那樣，VB6主線程可能並不真正與C＃線程兼容（特別是如果它具有任何WinForms或WPF交互），並且在互操作代碼中幕後執行一系列魔術以將線程連接在一起。我在過去發現，從DotNet調用的VB6應用程序調用的任何DoEvents最終都會導致某種掛起/硬件崩潰。 –

評論你的「DoItInCOM」方法，內核轉儲表示正在顯示一個模式對話框（可能爲COM方法調用中的錯誤的結果）。

.NET參數正在編組到COM端。如果您使用的是一些非標準的C＃類型，則可能會遇到序列化問題，但這裏不是這種情況。

如果你把在VB代碼中的「對錯誤轉到」處理程序，你可以很可能抑制會產生在UI線程上一個錯誤訊息。如果錯誤級別較低（VB運行時拋出它），則需要直接修復COM組件，以解決該問題。還要查看Windows事件查看器的VB運行時origintatin消息以獲取更多信息。

來源

2017-01-19 15:59:51

使用C＃插件在COM應用程序中掛起

回答

相關問題