Наше внутреннее приложение включает в себя объект Browser Helper Object (BHO) для работы с некоторыми асинхронными функциями (периферийные устройства и т. Д. c) путем вызова методов двух библиотек DLL, оно работает в Inte rnet Explorer на основе поддержки ActiveX.
Нам нужно исключить любое использование ActiveX и заставить приложение работать в других браузерах (например, Google Chrome), поэтому мы создали службу API REST, которая позволяет нам вызывать методы библиотек DLL и в большинстве случаев он работает нормально, однако для одного указанного c метода, когда служба API REST выполняет вызов, в Windows возникает нарушение прав доступа (0xC0000005) и служба останавливается, после большой отладки в вызываемой DLL мы обнаружили, что ошибка был в следующем фрагменте кода C ++. Этот код заставляет «перетекать» запросы / ответы к периферийному программному обеспечению с помощью MSMQ, он отлично работает при вызове IE ActiveX, но завершается неудачно при вызове API Rest Service:
while (TRUE)
{ // Wait until the main application thread asks this thread to do
// a process
dwRet = MsgWaitForMultipleObjects( 1 ,
&hEventEndThread ,
FALSE ,
INFINITE ,
QS_ALLINPUT );
if (dwRet == WAIT_OBJECT_0)
{ // Exit the thread if the main application sets the "end thread"
// event. The main application will set the "start process" event
// after setting the "end thread " event.
break; // Terminate this thread by exiting the proc.
}
else
{
if (dwRet == WAIT_OBJECT_0 + 1)
{
while (PeekMessage(&msg, NULL, NULL, NULL, PM_REMOVE))
{
TranslateMessage(&msg);
DispatchMessage(&msg); /// This is the line where the Windows Access Violation occurs
}
continue;
}
else
{
continue;
}
}
}
Мы нашли что исключение было выдано в DispatchMessage (& msg); и мы подозреваем, что этот код может быть привязан к функциональности IE BHO, но мы не уверены в этом или в способе его «исправить», мы попытались изменить флаги MsgWaitForMultipleObjects из QS_ALLINPUT со следующими результатами:
- QS_INPUT: исключений не было, но намеченный процесс не был перенесен
- QS_POSTMESSAGE: исключение
- QS_SENDMESSAGE: исключений не было, но намеченный процесс не был перенесен
Мы пробуем разные комбинации, но нам не нравится этот метод "угадывания", и поиски Google по поводу использования этих флагов не были очень проницательными.
Вопрос либо :
- Каким должно быть значение флагов для событий отправки / прибытия MSMQ? или
- Должны ли мы изменить подход MsgWaitForMultipleObjects, чтобы знать о событиях отправки / прибытия MSMQ?
ПРИМЕЧАНИЕ. Я полностью осознаю, что это сложный случай (мы пытаемся чтобы решить ее в течение нескольких дней) и попытался сделать абстракцию, которая могла бы быть опубликована как SO вопрос, я более чем готов переформулировать это жестко.
РЕДАКТИРОВАТЬ: Мы добавили некоторые записи и обнаружили, что исключение всегда происходит в третий раз, когда приходит какое-то сообщение (все это за одну секунду), мы также распечатали атрибуты msg и нашли следующие значения:
Wed Feb 05 17:34:38 2020 PeekMessage msg.message: 799
Wed Feb 05 17:34:38 2020 PeekMessage msg.wParam: 1
Wed Feb 05 17:34:38 2020 PeekMessage msg.lParam: 0
Wed Feb 05 17:34:38 2020 PeekMessage msg.hwnd: 2101766
Wed Feb 05 17:34:38 2020 PeekMessage msg.time: 113452640
Wed Feb 05 17:34:38 2020 PeekMessage msg.message: 799
Wed Feb 05 17:34:38 2020 PeekMessage msg.wParam: 1
Wed Feb 05 17:34:38 2020 PeekMessage msg.lParam: 0
Wed Feb 05 17:34:38 2020 PeekMessage msg.hwnd: 397728
Wed Feb 05 17:34:38 2020 PeekMessage msg.time: 113452640
Wed Feb 05 17:34:38 2020 PeekMessage msg.message: 49891
Wed Feb 05 17:34:38 2020 PeekMessage msg.wParam: 2304
Wed Feb 05 17:34:38 2020 PeekMessage msg.lParam: 82366828
Wed Feb 05 17:34:38 2020 PeekMessage msg.hwnd: 397728
Wed Feb 05 17:34:38 2020 PeekMessage msg.time: 113452640
Спасибо,
Иоганн