Как изменить расширение IE, чтобы устранить нарушение прав доступа в другом модуле (flash.ocx), приводящем к аварийному завершению работы IE?

Question

У меня есть расширение Internet Explorer (BHO), которое прекрасно работает на тысячах компьютеров, но в некоторых случаях кажется, что Flash приводит к сбою iexplore.exe с нарушением прав доступа. Что я могу попытаться сделать, чтобы избежать этого столкновения?

Больше деталей:

В среде одного клиента возникает ситуация, когда после посещения веб-сайта с помощью Flash и закрытия вкладки IE происходит сбой процесса вкладки. Это происходит только в том случае, если и Flash, и мое расширение включены и пока не могут быть воспроизведены на рабочих станциях за пределами среды этой компании. Это все еще происходит, если мое расширение сконфигурировано, чтобы ничего не делать на этой странице - то есть часть моего кода все еще выполняется, но очень мало.

Если веб-сайт не находится на доверенных сайтах, то вкладка работает в защищенном режиме, и в результате сбоя появляется окно, сообщающее, что веб-страница хочет запустить dw20.exe (т. Е. Dr Watson) ,

Если веб-сайт добавляется в доверенные сайты, то в журнал событий приложения Windows записывается ошибка, и IE снова открывает вкладку с небольшим сообщением в строке информации о том, что IE восстановил его после сбоя. В любом случае это расстраивает! Пользователю действительно все равно, произойдет ли сбой процесса при закрытии вкладки, поэтому я был бы рад обходному пути, который означает, что пользователю не показывается сообщение об ошибке и вкладка не открывается.

Журнал событий приложения Windows не говорит много, но он говорит, что процесс iexplore.exe завершился с ошибкой прошивки модуля:

Error / Application Error / EventID=1000

Faulting application name: iexplore.exe, version 9.0.8112.16592, time stamp 0x544e95a7
Faulting module name: Flash32_13_0_0_214.ocx, version 13.0.0.214, time stamp 0x5359c422
Exception code: 0xc0000005
Fault offset: 0x00073678
Faulting application start time: 0x01d0099db319df49
Faulting application path: C:\Program Files\Internet Explorer\iexplore.exe
Faulting module path: C:\Windows\system32\Macromed\Flash\Flash32_13_0_0_214.ocx
ReportId: 0094988b-7591-11e4-93e6-6cf0492a8610

Это была довольно новая версия flash, но не последняя. Они пытались обновиться до последней версии, но у них были те же симптомы.

На их рабочих станциях работает антивирус Sophos, и в некоторых редких случаях мы видели, как антивирус вызывал проблемы с нашим расширением. Мы протестировали после остановки всех служб Windows, которые упоминали Sophos, и возникла та же проблема, так что я уверен, что это не связано с этим.

Мое расширение построено с использованием.NET 3.5 SP1, что не является идеальным способом сделать это из-за потенциальных конфликтов времени выполнения с другими расширениями, но сейчас это так.

Если я отключу расширение, проблема исчезнет. Если я отключу Flash, проблема исчезнет. Неисправный модуль, являющийся Flash32_13_0_0_214.ocx Сильно указывает на то, что это ошибка, но теоретически это может быть проблемой в моем коде. Из моего расширения не выполняется неуправляемый код, поэтому этого не может быть, поэтому я не могу придумать, что может сделать мое расширение, что может вызвать AccessViolation. Это оставляет возможность ошибки во Flash, которая кажется вполне возможной, или проблему с тем, как я взаимодействую с COM-объектами из IE. Тем не менее, маловероятно, что команда Flash изучит такой отчет об ошибке, если я не укажу на что-то конкретное и воспроизводимое, и сейчас я не могу реплицироваться на каких-либо разработчиках, так что это не здорово. И даже если это ошибка Flash, с точки зрения клиента она ничем не отличается от ошибки в моем продукте: либо я исправлю ее, либо мой продукт будет удален, и они сохранят Flash.

Опции

На что я надеюсь, так это некоторые идеи о:

• Что я могу попробовать в своем коде / продукте, чтобы избежать конфликта с Flash? Например, будет ли надежда работать на перебазирование моих библиотек для перемещения моего расширения в другую область памяти? Будет ли возможность перекомпиляции для.NET 4.0/4.5 работать?

• Что я могу сделать, чтобы воспроизвести проблему... и почему это не будет проблемой в десятках других компаний, но будет проблемой в этой? Любые мысли о том, что может быть экологическим фактором, который вызывает проблему здесь, но не на рабочих станциях, настроенных по-другому?

• Есть ли смысл пытаться получить аварийный дамп или другую диагностическую информацию о сбое (например, ProcMon во время сбоя)? У меня нет опыта, чтобы пройти такую ​​диагностику, поэтому я бы хотел избежать ее, если только она не приведет меня к ответу о том, что я могу сделать по-другому в моем продукте, или точно укажу на точную ошибку во флэш-модуле (если там действительно это один).

• Я был бы счастлив, если бы он мог молча аварийно завершить работу, например, что-нибудь, чтобы IE не открывал вкладку в случае сбоя.

Может пройти некоторое время, прежде чем я найду время у клиента, чтобы протестировать различные варианты, поэтому я хотел бы попробовать несколько вещей. Любые идеи с благодарностью.

Некоторые случайные идеи, которые у меня были до сих пор. Любой из них стоит попробовать?

• перекомпилировать с использованием.net 4
• В моем методе SetSite (null) (событие, которое происходит, когда мое расширение выгружается) у меня есть несколько строк кода очистки, например Marshal.FinalReleaseComObject(webBrowser) а также GC.Collect(), Удалите один или несколько из них: возможно, очистка GC или COM портит пространство памяти Flash.
• перебазировать мои DLL.
• Деинсталлируйте и переустановите IE9 на рабочей станции, чтобы увидеть, оказывает ли это какое-либо влияние. Не решение, которое будет работать в масштабах всей компании, но может указывать на что-то хитрое с их имиджем IE.

Обновить

Клиент снова повторил проблему, и вместо Flash ocx неисправный модуль был jscript9.dll, Они также сообщили, что видели то же самое с ntdll.dll хотя я сам этого не видел

Faulting application name: iexplore.exe, version: 9.0.8112.16575, time stamp: 0x53ee1acb 
Faulting module name: jscript9.dll, version: 9.0.8112.16575, time stamp: 0x53ee1c49 
Exception code: 0xc0000005 
Fault offset: 0x00007264 
Faulting process id: 0x1bb4 
Faulting application start time: 0x01cfec57f247cb53 
Faulting application path: C:\Program Files\Internet Explorer\iexplore.exe 
Faulting module path: C:\Windows\System32\jscript9.dll 
Report Id: 50b58f63-584b-11e4-bc66-6cf0492a8610 
Faulting package full name: %14 
Faulting package-relative application ID: %15

Так что я думаю, что это открывает, что не связано с Flash...

Answer 1

Проблема в том, что с.Net вы практически ничего не можете сделать, чтобы активно испортить память. Так что, если вы не много играете с вызовами Api, действительно сложно, что-то в вашем коде вызывает ошибку.

Переезд dll кажется мне наиболее многообещающим занятием; не возиться с GCC тоже кажется действительно хорошим вариантом (и это ВСЕГДА, не только в этом случае).

Другая проблема заключается в том, что неисправен не ваш модуль, и к этому следует серьезно отнестись: это не ваш код пытается достичь области памяти, malloc'ed другой dll, но это их код, пытающийся связываться с памятью вашей dll пространство.

Вероятно, ваша лучшая ставка - DW; позволив ему сохранить дамп, вы можете пройти через трассировку стека, чтобы найти код, вызывающий проблему. Снова проследив, вы можете найти момент, когда какой-то параметр станет мусором. Наконец, вы можете использовать этот https://msdn.microsoft.com/en-us/windows/hardware/hh852365 для устранения неполадок в режиме реального времени. Зачем все это? Ну, потому что, если вы не делаете ничего странного в своей dll (например, вручную malloc'ing), в.Net вы никак не можете связываться с памятью, чтобы вызвать 0x05 в другой dll; На 99% именно этот IE с его конкретной конфигурацией является причиной всего, поэтому самым быстрым решением будет отладка, поиск кода, вызывающего проблемы, затем архивирование каждой имеющейся у вас информации и отправка ее по почте в MS.