Случаи с BSoD: ищем подсказки в аварийном дампе и в Сети

Мои последние публикации в блоге были посвящены «эстетической» стороне «синих экранов смерти» – в них я рассказывал, как настроить цвета BSoD. Надежность кода режима ядра Windows становится лучше с каждым выпуском, так что многие из вас никогда не столкнутся с BSoD. Но если вы все же увидели его (речь идет не о BSoD, который вы вызвали с помощью утилиты Notmyfault), то, как я объяснял в серии семинаров «Необъяснимые случаи» (Case of the Unexplained), несколько минут, потраченные на нахождение его причины, могут спасти вас от неудобств и возможной потери данных, которая может произойти при повторном сбое системы. В этой статье я, для начала, рассмотрю основы анализа аварийного дампа. Во многих случаях этот простой анализ приведет вас к некорректному драйверу, для которого есть новая версия, доступная в сети, но иногда результаты этого анализа неоднозначны. В качестве примера я использую случай с двумя администраторами, которые сообщили мне, что поиск в Сети по правильным ключевым словам привел их к решению проблемы.

Отладка сбоя начинается со скачивания пакета Debugging Tools for Windows (это часть WindowsSDK – заметьте, что вы можете провести веб-установку только Debugging Tools, вместо того, чтобы загружать и устанавливать весь SDK), его установки и настройки, которая заключается в указании сервера символов Microsoft, чтобы отладчик мог загрузить символы для ядра, которые нужны для интерпретации информации из дампа. Вы можете сделать это, открыв диалоговое окно настройки символов из меню File и введя URL сервера символов вместе именем папки в вашей системе, куда отладчик будет кэшировать скачиваемые им файлы символов:

Следующим шагом является загрузка аварийного дампа в отладчик с помощью команды Open Crash Dump меню File. Место хранения системой файлов дампа зависит от того, какую версию Windows вы используете, и является ли она серверной или клиентской. Есть простое правило, которое поможет вам найти файл дампа. Согласно ему, первое, что вам следует сделать, это проверить файл с именем Memory.dmp в папке SystemRoot (обычно C:\Windows); если вы не нашли его, посмотрите в папку %SystemRoot%\Minidump и загрузите новейшие файлы минидампа (предполагается, что вы хотите отладить последний сбой системы).

Когда вы загрузите файл дампа в отладчик, он использует эвристику, что попытаться определить причину сбоя системы. Он укажет вам на возможную причину, отобразив строку “Probably caused by:" с именем драйвера, компонента Windows или типа аппаратной ошибки. Вот пример, который правильно идентифицирует проблемный драйвер, ставший причиной сбоя, myfault.sys:

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

Если вы не нашли никаких подсказок, попробуйте выполнить поиск в Сети по текстовому описанию кода сбоя (его можно получить с помощью команды !analyze -v) и любых ключевых слов, которые описывают машину или программное обеспечение. Например, один администратор столкнулся с периодическими сбоями в работе серверной фермы Citrix. Он не знал, что мог посмотреть файл аварийного дампа, пока не посмотрел презентацию из серии «Необъяснимые случаи». После того, как он вернулся в свой офис с конференции, он открыл дампы с нескольких проблемных систем. Анализ привел к тому самому классическому выводу для большинства сбоев – драйвер не освободил память ядра, связанную с удаленными пользовательскими сеансами, когда это было необходимо:

В надежде, что поиск в Сети может дать ему подсказку, он ввел “session_has_valid_pool_on_exit and citrix” в поисковую строку браузера. К его изумлению, самая первая ссылка вела на страницу базы знаний Citrix с описанием решения именно этой проблемы, и в той статье даже был скриншот точно такого же окна отладчика с результатами анализа, которые он видел на своей системе:

После загрузки и установки исправления ферма серверов стала работать нормально.

В другом примере администратор столкнулся с тремя сбоями сервера на протяжении нескольких дней. К сожалению, анализ не указал на решение, а просто сообщил, что сбой, вероятно, связан с тем, что некий внутренний сторожевой таймер не сработал на протяжении заданного промежутка времени:

Как и в предыдущем случае, администратор ввел текст сбоя в поисковую строку и, к его облегчению, самая первая ссылка результатов поиска вела к описанию решения этой проблемы:

После установки исправления, сервер больше не сталкивался со сбоями.

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

Comments

• Anonymous
  December 27, 2013
  Pingback from ???????????? ?? BSoD: ???????? ?????????????????? ?? ?????????????????? ?????????? ?? ?? ???????? | UC3