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

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

Интерфейс 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 отображает список обнаруженных в системе дампов памяти. Здесь я перечислю только основные столбцы верхнего фрейма программы:

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

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

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

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

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

Собственно, вкратце, общий алгоритм поиска причины сбоя следующий:

1. (в верхней части окна) ставим курсор на имя интересующего нас минидампа, тем самым выделяя (выбирая) его. Нижняя часть окна автоматически заполняется результатом анализа.
2. (в верхней части окна) смотрим столбец Caused By Driver, видим там наименование проблемного модуля/драйвера (для нашего случая это RtkHDAud.sys).
3. (в нижней части окна) находим этот же драйвер/модуль (столбец Filename), ставим курсор на эту строку и опять перемещаем ползунок вправо, чтобы посмотреть значения в столбцах Product Name, File Description и Full Path. По значениям этих полей мы сможем определить принадлежность модуля/драйвера. Если же поля нам не дали никакой информации, то вбиваем имя модуля/драйвера RtkHDAud.sys в поисковик и ищем информацию уже в Сети.

Изредка встречаются случаи, когда указываемый в верхнем фрейме программой BlueScreenView драйвер не является источником проблемы. Да, ведь сам автор, как я писал уже выше, предупреждает от том, что невозможно сделать точный вывод по сбою в 100% случаев. Однако, не стоит отчаиваться, поскольку драйвер/модуль, который является истинным виновником сбоя, наверняка присутствует среди списка, подсвеченного красным цветом в нижней части окна программы. У нас это: ks.sys, ntoskrnl.exe, portcls.sys, sysaudio.sys, wdmaud.sys. Исходя из отсутствия 100% гарантии определения, в исследовании аварийных дампов я бы не ограничивался применением только лишь утилиты BlueScreenView, а использовал бы и другие продукты для анализа проблемы.