У Дэвида Соломона (David Solomon), моего соавтора по книгам Windows Internals, недавно был очень важный разговор в VoIP-сети Skype, когда звук неожиданно исказился. Через секунду привычный рабочий стол сменил BSOD. После того, как он перезагрузил компьютер, он перезвонил, но через полчаса голос собеседника снова прервался на середине, а потом на экране возник очередной BSOD. Так как разговор все равно подходил к концу и причина падений была не ясна, Дэвид решил не перезванивать, считая, что формально разговор уже закончен, но зато решил разобраться в причинах сбоя. Он запустил Windbg из пакета Debugging Tools for Windows, в меню выбрал пункт Open Crash Dump и выбрал файл %Systemroot%\Memory.dmp.
До этого он настроил Windbg на использование публичного сервера символов Microsoft, введя для этого srv*c:\symbols*http://msdl.microsoft.com/download/symbols в диалоговом окне Windbg по настройке символов, поэтому Windbg знал, как интерпретировать dump-файл. Когда Windbg загружает файл дампа, то он автоматически инициирует эвристический механизм анализа, который и определяет драйвер или компонент системы, который, вероятнее всего, и виноват в сбое. Результат анализа указал на драйвер устройства NETw4v64.sys.
Когда в результатах вы щелкаете по ссылке !analyze -v, Windbg выводит данные, используемые во время анализа. Эвристический анализ не идеален, поэтому Дэвид всегда щелкает по этой ссылке, чтобы получить дополнительные данные, в особенности трассировку стека на момент сбоя и информацию о возможных участках данных, связанных со сбоем. В трассировке стека записан постоянный повторяющийся вызов функции процессора, который и привел к сбою ядра — KeBugCheckEx. В данном случае стек выглядел следующим образом:
Для сохранения хронологии вызова функций записи в стеке необходимо читать снизу вверх. Трассировка показывает, что какой-то код в NETw4v64 вызывает функцию NT-ядра KeAcquireSpinLockRaiseToDpc. Фрейм стека NETw4v64 не имеет текстового имени функции, которое должно быть у драйверов, не являющихся частью Windows, и, как следствие, не имеют символов на сервере символов Microsoft. Следующий, более высокоуровневый фрейм, показывает, что KeAcquireSpinLockRaiseToDpc вызывал KiPageFault, скорее всего, не напрямую, но это произошло в результате ссылки на адрес виртуальной памяти, которая на тот момент не была резидентной в физической памяти. Потом KiPageFault вызвал функцию KeBugCheckEx с кодом остановки А, который расширенный анализ описал как IRQL_NOT_LESS_OR_EQUAL:
Дэвид предположил, что NETw4v64 вызывал драйвер с помощью неправильного указателя, который вызывал неправильную ссылку на память. Этот конкретный сбой мог быть результатом случайного повреждения, вызванного сторонним драйвером, поэтому он открыл папку %Systemroot%\Minidump в поисках дампа первого сбоя системы. В Windows Vista, в которой работал Дэвид, система всегда записывает дамп памяти и ядра в файл, расположенный по адресу %Systemroot%\Memory.dmp, при этом перезаписывая предыдущий дамп, и сохраняет укороченную версию дампа, называемую минидамп, в папку %Systemroot%\Minidump. После этого Дэвид проделал те же шаги и со вторым дампом и механизм анализа сообщил о той же самой причине сбоя, указав на тот же самый поврежденный указатель значения памяти.
Без тщательного ручного анализа дампа вы не можете быть уверенными в том, что виноват эвристический указатель драйвера, но первое правило при расследовании сбоя состоит в том, чтобы проверить наличие последних версий драйверов. Иногда на Windows Update появляются опциональные обновления, которые не применяются к системе автоматически, поэтому Дейв зашел в папку %Systemroot%\System32\drivers, чтобы найти драйвер NETw4v64.sys и разобраться, какое устройство его использует. В диалоговом окне свойств файла было сказано, что файл имеет версию 11.5 и относится к Intel Wireless WiFi Link Driver.
Вооруженный знаниями о том, что это драйвер беспроводного адаптера Intel, Дейв зашел в диспетчер устройств, раскрыл ветку сетевых адаптеров и, к своему удивлению, нашел устройство с похожим именем:
Чтобы запустить мастер обновления, в контекстном меню он выбрал опцию обновления драйверов и запустил автоматический поиск на Windows Update. К сожалению, система отрапортовала, что в системе установлена новейшая версия драйвера.
Иногда на сайтах у OEM-производителей есть драйвера, которые они еще не опубликовали в Windows Update, поэтому Дейв зашел на сайт Dell, производителя его ноутбука, и проверил там. К сожалению, ситуация опять повторилась — там был такой же драйвер.
OEM-производители, в свою очередь, часто обращаются к производителям устройств за созданием устройства, соответствующего определенным требования по стоимости, питанию, возможностям или размеру. Вследствие этого производители оборудования не публикуют драйвера для каждого отдельного OEM-устройства, равно как и общие драйвера, которые могут и не использовать все функции конкретного OEM-устройства. Поэтому Дэвид зашел на сайт Intel. К его удивлению, там нашлась не только версия драйвера, которая безо всяких проблем установилась и заработала на его компьютере: выяснилось, что драйвер от Intel имел версию 12.1, то есть на целую версию выше, чем тот, который размещает на своем сайте Dell.
Intel предлагает для загрузки архив с драйверами объемом менее 7 МБ, что немного-немало в 10 раз меньше пакета от Dell, при этом в комплект входит дополнительное программное обеспечение для управления устройством.
Дейв не смог окончательно закрыть дело, так как у него не было уверенности, что именно драйвер от Intel был причиной сбоя, но после установки новой версии драйвера сбоев системы более не наблюдалось. Даже если основной причиной был не драйвер от Intel, Дейв все равно был доволен установкой новой версии драйвера, которая оказалась более производительной, надежной и более экономичной в плане потребления питания. Это дело является отличным уроком по анализу дампов и хорошим примером того, что даже на Windows Update и сайтах OEM-производителей могут быть не самые новые версии драйверов. Надеюсь, что Dell впредь будет использовать Windows Update, чтобы рассылать своим пользователям новейшие версии драйверов.
Источник: http://blogs.technet.com/markrussinovich
Tags: analyze, voip, Windows Vista