Tôi gặp sự cố khi ứng dụng của chúng tôi treo trên máy khách hàng mà tôi đã sử dụng trong nhiều ngày mà không cần giải quyết. Vấn đề phát sinh khá ngẫu nhiên từ những gì chúng ta đã thấy, mặc dù điều đó có thể không đúng. Khách hàng cũng báo cáo rằng CPU đang đạt đỉnh khi ứng dụng bị treo.Treo trong ứng dụng COM với trình cắm C#
Vấn đề là tôi không biết ứng dụng bị lỗi (treo) ở đâu. Chúng tôi cũng có một số plugin được viết bằng C# làm plugin cho ứng dụng COM chính.
Tôi đã quản lý để đưa khách hàng thực hiện một MiniDump với ProcExp trên một máy nơi xảy ra sự cố. Tuy nhiên, tôi không phải rất quen thuộc với WinDBG hoặc MiniDumps hoặc cho vấn đề đó. Tôi đã chạy !analyze -v và !analyze -v -hang, sản xuất một số đầu ra, bao gồm cả ngăn xếp bên dưới. Đối với những gì tôi có thể nói, có vẻ như ứng dụng đang chuyển đổi sang một trong các plugin C# của chúng tôi (CLR) và sau đó quay lại COM, đây là giao diện quay lại ứng dụng chính có sẵn cho các plugin. Nhưng sau đó thì? Có thể nói điều gì đó khác từ ngăn xếp này không?
Ứng dụng chính được viết bằng VB6 nếu có vấn đề.
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.
Sửa 1: Vài suy nghĩ rằng tôi đã có sau khi đọc một số bài viết diễn đàn khác. Dường như với tôi rằng treo được giới thiệu sau một marshaling của các loại dữ liệu từ .NET đến COM. Bây giờ tôi đã đọc về another problem mà dường như bắt nguồn từ thực tế là các biến cục bộ được chuyển vào một phương thức COM đã được thu thập rác và do đó thời gian chạy VB6 gặp sự cố khi xử lý bộ nhớ deallocated. Đó là bài viết khác không chính xác vấn đề này, nhưng nó làm cho tôi nghĩ.
Trong mã NET gọi vào COM chúng tôi có loại mã
void SomeNETMethod(MyObject obj, bool doIt) {
string someString = obj.SomeString;
this.myComComponent.DoItInCOM(ref someString, ref doIt); // This is where it hangs.
}
Có thể các ref bool cũng như trực tiếp từ phương pháp để phương pháp truyền thông số đã bất cứ điều gì để làm với bất cứ điều gì? Như bạn có thể thấy, tôi đang lúng túng trong bóng tối ở đây ...
VB6 và chủ đề là nước và lửa. Có vẻ như bế tắc khi luồng chính của VB6 ngừng bơm vòng lặp tin nhắn. Bạn cần trình sửa lỗi VB6 để tìm hiểu xem nó đang làm gì. –
@ HansPassant có thể xảy ra những vấn đề này mặc dù các plugin C# của chúng tôi không phải là đa luồng? Chủ đề 'khác' duy nhất mà tôi có thể thấy được phát ra ở đây là chuỗi GC, nhưng tôi cho rằng đó không phải là vấn đề. – lbergnehr
Có một DoEvents nào đó trong mã VB6 được gọi không? Như @HansPassant chỉ ra, VB6 chủ đề chính có thể không thực sự tương thích với các chủ đề C# (đặc biệt là nếu nó có bất kỳ tương tác WinForms hoặc WPF) và một loạt các phép thuật được thực hiện đằng sau hậu trường trong mã interop để buộc các chủ đề với nhau.Tôi đã tìm thấy trong quá khứ mà bất kỳ DoEvents gọi từ một ứng dụng VB6 đang được gọi từ DotNet cuối cùng sẽ dẫn đến một số loại treo/cứng sụp đổ. –