Повесьте приложение COM с плагином С#

91
7

У меня проблема, когда наше приложение зависает на машинах наших клиентов, на которых я работал уже несколько дней без решения. Проблема возникает довольно случайно из того, что мы видели, хотя это может и не быть истинным случаем. Клиент также сообщает, что процессор достигает максимума, когда приложение зависает.


Проблема в том, что я понятия не имею, где приложение терпит неудачу (висит). У нас есть пара плагинов, написанных на С# в качестве плагинов для основного COM-приложения.


Мне удалось заставить клиента взять MiniDump с ProcExp на машине, где возникла проблема. Однако я не очень хорошо знаком с WinDBG или MiniDumps. Я запустил !analyze -v и !analyze -v -hang, который производит некоторый вывод, включая стек ниже. Для того, что я могу сказать, кажется, что приложение переходит в один из наших плагинов С# (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. Теперь я прочитал о еще одной проблеме, которая, по-видимому, возникла из-за того, что локальные переменные, переданные в 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-24T10:23:00+04:00 8 лет, 4 месяца назад
1
Решение
65

Просмотрите свой метод "DoItInCOM", так как дамп ядра указывает, что отображается модальный диалог (вероятно, в результате ошибки в вызове метода COM).


Параметры .NET правильно сортируются на стороне COM. Если вы использовали нестандартный тип С#, вы можете столкнуться с проблемой сериализации, но здесь это не так.

Если вы разместите обработчик "On Error Goto" в коде VB, вы, вероятно, можете подавить ошибки, которые будут генерировать сообщение в потоке пользовательского интерфейса. Если ошибка на более низком уровне (время выполнения VB ее выбрасывает), вам нужно будет решить эту проблему с исправлениями непосредственно в COM-компоненте. Также ознакомьтесь с просмотром событий Windows Viewer для VB Runtime origintatin для получения дополнительной информации.

ответил(а) 2017-01-19T18:59:00+03:00 3 года, 4 месяца назад
Ваш ответ
Введите минимум 50 символов
Чтобы , пожалуйста,
Выберите тему жалобы:

Другая проблема