Vista: дело о неслучайном сбое веб-браузера Internet Explorer 8

***

…Как известно, веб-браузер Internet Explorer 8 использует многопроцессную модель, в которой различные вкладки располагаются в разных процессах, – это сделано для того, чтобы «падение» одной вкладки не вызывало «падение» других. Но всё же «падения» браузера бывают, и весьма часто!..

В течение длительного времени автора статьи «доставала» проблема, которую с наскока решить не удавалось.

А дело было вот в чем: при закрытии браузера Internet Explorer 8 (ноутбук Acer; 32-битная Windows Vista SP2; ОЗУ – 2,5ГБ; процессор Intel Celeron 1,73ГГц) зачастую – без явной причины! – появлялось окно Microsoft Windows с сообщением «Прекращена работа Interner Explorer. При следующем подключении к Интернету Windows может провести поиск способа устранения этой ошибки»:

Доступные опции:

– Проверить наличие способа исправления ошибки в Интернете позднее и закрыть программу;

– Закрыть программу.

Выбор первой опции, а также обращение к Базе Знаний Майкрософт были безрезультатными.

При нажатии на кнопку Показать подробности проблемы (в окне с сообщением об ошибке) можно было ознакомиться со следующей информацией:

Как правило, в сообщениях об ошибке был указан «модуль с ошибкой» mshtml.dll (изредка – ntdll.dll).

Начинаем изучение проблемы с «ошибочного» модуля.

Файл mshtml.dll (дисковый адрес – \Windows\System32\) – это Средство просмотра HTML Microsoft.

Попытка перерегистрировать модуль mshtml.dll (с помощью сервера регистрации regsvr32.exe – команда regsvr32 /i mshtml.dll) была безрезультатной:

Файл ntdll.dll (дисковый адрес – \Windows\System32\) – это Системная библиотека NT (является прослойкой между Win32 API и NT Native API; вызывает прерывания при обращении к ядру системы – через ntdll.dll – других библиотек). Если бы сбоил ntdll.dll, то многие приложения при работе «падали» бы, – но сбой наблюдался только при завершении (именно при завершении!) работы Internet Explorer 8.

Тестирование оперативной памяти показало, что она исправна.

Проверка системных файлов Windows (с помощью команды SFC /SCANNOW) также не выявила поврежденных (или измененных) файлов.

Ну что ж, задействуем «тяжелую артиллерию» – утилиту Process Explorer и отладчик WinDbg.

Запускаем Process Explorer, находим процесс WerFault.exe:

Следует отметить, что когда происходит сбой какого-либо процесса, служба Windows Error Reporting (WER) запускает – в сеансе ошибочного процесса – свой процесс (WerFault.exe), передавая идентификатор (PID) сбойного процесса в командную строку WerFault (при этом отображается диалоговое окно с сообщением об ошибке).

Для открытия диалогового окна свойств процесса надо выделить его и выбрать меню Process –> Properties… (или дважды нажать процесс левой кнопкой мыши, или нажать правой кнопкой мыши и выбрать из контекстного меню Properties…).

Командная строка (Command line) процесса WerFault.exe содержит PID сбойного процесса Internet Explorer 8 (в рассматриваемом случае этот идентификатор можно было узнать и в основном окне Process Explorer):

Узнав PID сбойного процесса (4776), запускаем отладчик WinDbg.

Для поиска возможных причин сбоя с помощью отладчика нужно просматривать стек каждого потока в процессе, поэтому с помощью меню View открываем окна Processes and Threads (можно для вызова окна нажать Alt+9) и Call Stack (Alt+6). Для удобства пользования располагаем окна рядом.

С помощью меню File –> Attach to a Process… (или с помощью клавиши F6) открываем диалоговое окно Attach to a Process:

Находим (по идентификатору 4776) сбойный процесс, к которому необходимо подключиться, выделяем его (в текстовом поле Process ID должен отобразиться идентификатор процесса) –> OK.

Сначала пробуем использовать встроенную функцию эвристического анализа: в командной строке WinDbg вводим команду !analyze.

Увы, использование эвристики не помогло, в разных сбойных случаях она показывала, что возможный виновник сбоев то файл ntdll.dll

то оперативная память

Будем искать сбойный поток вручную.

В окне Processes and Threads поочередно выбираем каждый поток и нажимаем Enter (или дважды нажимаем его левой кнопкой мыши):

В окне Call Stack просматриваем стек, отыскивая функции, в именах которых присутствуют слова exception, fault, unhandled.

Наконец-то в окне стека вызовов обнаружено искомое:

Но – увы! – dll-библиотеки, указанные в стеке вызовов сбойного процесса, являются системными файлами Windows: ntdll.dll (о котором речь уже шла выше) и kernel32.dll (Библиотека клиента Windows NT BASE API; дисковый адрес – \Windows\System32\).

Поскольку в стеке вызовов сбойного процесса наличествует строка WARNING: Stack unwind information not available. Following frames may be wrong, используем функцию Display Words and Symbols для поиска пропущенных кадров стека с адресами функций. Так как операционная система – 32-разрядная, используем dds-версию этой функции. В командной строке отладчика вводим dds, а в качестве адреса (предоставляемого команде как стартовая точка) берем адрес фрейма стека, который расположен прямо над «потерянным» адресом (0568f864):

Выявить виновника сбоев не удалось, – вероятно, обратные адреса вызванных сбойным потоком функций были затерты ошибкой, вызвавшей сбой…

Напоследок просматриваем список загруженных модулей. Для этого воспользуемся командой lm (List Modules):

Всего на момент сбоя было загружено 130 (!) модулей (выгружено к моменту сбоя 12).

Теоретически любой из 130 загруженных модулей мог быть причиной сбоя…

Да, как говорится, есть повод задуматься!..

Конечно, продолжая дальнейшую – скрупулезную! – работу с отладчиком, в конце концов виновника сбоев удалось бы выявить.

Как говорится, мы победим, но мы пойдем другим путем – более простым.

***

А вот и он – простейший путь решения проблемы!

Предположив, что причина сбоев кроется всё-таки не в самом IE8 (следует отметить, что, например, на ноутбуке Asus с 64-битной Windows 7 браузер Internet Explorer 8 работал стабильно, без «падений»), а в одной из надстроек, которыми он буквально «увешан», открываем окно Свойства обозревателя (кстати, это диалоговое окно можно вызвать как в самом веб-браузере – с помощью меню Сервис –> Свойства обозревателя, так и с помощью Пуск –> Панель управления –> Свойства обозревателя);

– на вкладке Программы нажимаем кнопку Настроить надстройки;

– в диалоговом окне Надстройки выбираем типы надстроек Панели инструментов и расширения;

– в прокручиваемом списке проверяем все надстройки, загруженные на текущий момент;

– интуитивно решено отключить Adobe PDF Link Helper – Объект модуля поддержки обозревателя (\Program Files\Common Files\Adobe\Acrobat\ActiveX\AcroIEHelperShim.dll) –> Отключить –> Закрыть.

Проверяем работу Internet Explorer 8.

Сбой устранен! Дело о неслучайном сбое веб-браузера закрыто.

Следующим этапом станет тщательная – профилактическая! – работа с другими надстройками IE8…

***

В заключение, хочу поблагодарить всех, без кого эта статья не была бы написана:

– Билла Гейтса, который «заварил всю эту кашу» (но которому мы за это безмерно благодарны!);

– корпорацию Microsoft (во-первых, за глюки ее программного обеспечения, отсутствие которых многих айтишников оставило бы без работы; во-вторых, за прекрасный программный пакет – иногда мне кажется, что во всём ПО Micosoft не глючит только он! – Debugging Tools for Windows, которым любой желающий программист/разработчик/сисадмин может воспользоваться бесплатно);

– корпорацию Adobe Systems (глюки ее программного обеспечения тоже дают хлеб насущный многим айтишникам);

– Марка Руссиновича – за его ценные советы и бесценные утилиты;

– и многих-многих других (в том числе тех, кто будет читать эту статью!).

Да пребудет с нами Сила!..

Валерий Сидоров

***

• Internet Explorer 8: ставить или нет?

English version