BlueScreenView - анализ аварийного дампа памяти

Метки:  , , ,

Данная статья продолжает серию публикаций по обзору инструментов анализа аварийных дампов системы. И сегодня мы рассмотрим пожалуй наиболее автономное средство в арсенале специалиста, утилиту с говорящим названием BlueScreenView. Чем это средство так уникально? Не тем, что алгоритм работы программы в какой то степени отличается от алгоритмов программ подобного класса (скорее всего всё крутится вокруг одних и тех же условий), а более из-за того, что программа не использует отладочные символы, что делает её полностью независимой. BlueScreenView представляет собой бесплатное программное обеспечение, которое анализирует содержимое файлов дампов, создаваемых при критическом сбое системы (BSOD, синий экран смерти), и предоставляет информацию пользователю в виде легко интерпретируемой результирующей таблицы. Утилита, в дополнение, предоставляет еще и расширенную информацию по свойствам дампов памяти системы. Ко всему прочему, как уже отмечалось, BlueScreenView полностью автономна и не требует для своей работы никаких дополнительных дынных, как то символы либо отладчики. Скачал, запустил, проанализировал! Автором программы является Nier Sofer, хотел бы сказать спасибо ему огромное за предоставленную миру полезнейшую утилиту.
Скачать BlueScreenView можно по вот этой ссылке. При этом, что действительно удобно, так это то, что скачать утилиту можно не только в виде классического инсталлятора (зачем мне инсталлировать временный софт на сервер?), но и в форме отдельного переносимого (portable) приложения (пункт Download BlueScreenView (in Zip file)). Распаковал из архива и запустил, что еще надо? Опять же, это позволяет держать утилиту в наборе своих "инструментов на каждый день". BlueScreenView доступна в двух вариантах кода - в 32- и 64-битном.

Интерфейс BlueScreenView

После старта утилита BlueScreenView сканирует стандартное местоположение дампов памяти:

Анализ аварийного дампа с помощью BlueScreenView

и находит все дампы, которые располагаются в каталоге по-умолчанию, далее для каждого дампа по своему собственному алгоритму перечисляет адреса памяти внутри стека момента сбоя и определяет все драйвера/модули которые могут быть причиной критической ситуации.
По умолчанию BlueScreenView ищет дампы в каталоге %SystemRoot%\Minidump. Однако, данное положение может быть изменено редактированием параметра "Load from the following MiniDump folder" в разделе "Options" - "Advanced Options" (Ctrl+O). В дополнение, вид окна программы легко и удобно настраивается, что позволяет показывать/скрывать определенные столбцы.

Верхнее окно интерфейса программы BluScreenView по-умолчанию выглядит несколько иначе. На моем скриншоте я замаскировал (скрыл) четыре столбца под названием "Parameter 1", "Parameter 2", "Parameter 3", "Parameter 4", которые являются четырьмя аргументами функции KeBugCheckEx.

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

Столбец Назначение
Dump File Файл дампа памяти, найденный утилитой в заданной директории. Хранит различную информацию о состоянии системы на момент критической ошибки.
Bug Check String Символическое имя или описание критической ошибки (Bug Check) по классификации Microsoft. В нашем примере это BAD_POOL_HEADER.
Caused By Driver Драйвер или модуль, который, предположительно и вызвал сбой. BluScreenView пытается вычислить драйвер/модуль по стеку момента критического сбоя, который присутствует в дампе. В нашем случае RtkHDAud.sys. Помните, что механизм определения сбойного модуля/драйвера не может со 100% вероятностью определить виновника, и необходимо анализировать более расширенный список в нижнем фрейме окна программы, выделенный розовым цветом. Сам автор предупреждает нас об этом на странице утилиты.
Bug Check Code Идентификатор кода BugCheck или STOP-ошибка. Например, STOP 0x00000019.
Caused By Address Тоже самое что и колонка "Caused By Driver", однако показывает относительный адрес инструкций, вызвавшей сбой. Относительно начала модуля в котором произошел сбой. В нашей ситуации RtkHDAud.sys+1f93fc.
File Description Описание проблемного файла.
Crash Address Адрес по которому и случилась ошибка. Содержимое регистров EIP/RIP на момент сбоя. В некоторых случаях идентичен адресу из колонки "Caused By Address", в других адрес не совпадает. Пример: ntoskrnl.exe+22f5f.

В нижней части интерфейса BlueScreenView отображает список всех драйверов режима ядра, которые в момент сбоя находились в памяти. И маркирует розовым цветом все драйвера, которые найдены в стеке сбоя. Перечислю в таблице лишь основные столбцы:

Столбец Назначение
Filename Имя драйвера/модуля.
Address In Stack Адрес памяти драйвера, который найден в стеке.
From Address Смещение первого байта драйвера в адресном пространстве ядра. Пара значений From Address / To Address показывает адресное пространство, занимаемое драйвером.
To Address Смещение последнего байта драйвера в адресном пространстве ядра. Пара значений From Address / To Address показывает адресное пространство, занимаемое драйвером.
Size Размер драйвера в памяти.
Product Name Имя продукта, в состав которого входит драйвер. Загружается из поля ресурсов?
File Description Описание файла драйвера. Загружается из поля ресурсов?
File Version Версия файла драйвера. Загружается из поля ресурсов?
Company Имя компании. Загружается из поля ресурсов?.
Full Path Полный путь до файла драйвера в файловой системе.

В один прекрасный момент, анализируя очередной дамп памяти при помощи программы BlueScreenView я обратил внимание на одну интересную особенность. Если Вы внимательно посмотрите на столбец в верхнем фрейме программы под названием "Caused by Address", то увидите, что в нем присутствуют имена модулей/драйверов и относительный адрес инструкции. Так вот, почему же там присутствуют голые числовые значения смещений, но не имена? Причина проста.

BlueScreenView не использует отладочные символы и не нуждается в них.

То есть он ничего не знает о сопоставлении адресов реальным функциям. Конечно, это не позволяет программисту получить более детальную информацию, однако это абсолютно не нужно рядовому пользователю, которому для решения задачи достаточна и более общая информация о сбое, обобщенная до указания на модуль/драйвер. Как это сказывается на точности определения причины критической ошибки, спросите Вы? Пока что ответить на этот вопрос для меня сложновато, но могу предположить что никак не отражается, поскольку точность определения зависит от корректности работы внутреннего алгоритма BlueScreenView, который опирается на адреса памяти, но никак не зависит от наличия/отсутствия символов системы/модулей/драйверов. Символы нужны для дополнительной информации по внутренним функциям. С другой стороны, отсутствие использования символов для сторонних модулей/драйверов имеет под собой вполне весомое обоснование, Вы все-равно, в большинстве случаев, не сможете получить отладочные символы для них, поскольку их придется запрашивать у разработчика.

Анализ результатов

Собственно, вкратце, общий алгоритм поиска причины сбоя следующий: ставим курсор на имя интересующего нас минидампа, тем самым выделяя его. Крутим ползунок вправо и смотрим столбец Caused By Driver, видим там наименование проблемного модуля/драйвера. В нашем случае это RtkHDAud.sys. Находим его же в нижнем фрейме окна BlueScreenView, ставим курсор на данную строку и опять перемещаем ползунок вправо, чтобы посмотреть поля Product Name, File Description и Full Path. Если описанные поля имеют значения, то по этим данным мы сможем с некоторой вероятностью определить принадлежность модуля/драйвера. Если же поля нам не дали никакой информации, то вбиваем имя модуля/драйвера RtkHDAud.sys в поисковик и ищем информацию уже в Сети.
Изредка встречаются случаи, когда указываемый в верхнем фрейме программой BlueScreenView драйвер не является источником проблемы. Да, ведь сам автор, как я писал уже выше, предупреждает от том, что невозможно получить точный анализ сбоя в 100% случаев. Однако, не стоит отчаиваться, поскольку драйвер/модуль, который является истинным виновником сбоя, наверняка присутствует среди списка, подсвеченного красным цветом в нижней части окна программы. У нас это: ks.sys, ntoskrnl.exe, portcls.sys, sysaudio.sys, wdmaud.sys. Исходя из данного факта, в исследовании аварийных дампов я бы не ограничивался применением только лишь утилиты BlueScreenView, а использовал бы и другие продукты для анализа проблемы.

  • Поделиться:

2 комментария:

  1. Артур

    Столбца Caused By Driver просто нет, не существует в программе! Что за фигня!? Что делать? Версия программы 1.55, скачанная отсюда.

    • einaare

      так не отсюда же :) посмотрите внимательнее на ссылку - с сайта автора. Попробуйте развернуть на весь экран и поскролить горизонтально.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *