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, а использовал бы и другие продукты для анализа проблемы.

9 комментариев:

  1. Артур

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

    • einaare

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

  2. dimon4ik9009

    Столюцы Caused By Driver и Caused By Address пустые. Драйверов подсвеченных розовым цветом во втором окне нету. А синий экран у меня начинает вылетать всё чаще. На самом же синем экране высвечивает драйвер srv.sys но в программе он не розовый, а просто белый.
    pls help :(

  3. Валерий

    Добрый день, у меня такой вопрос: Windows 7 64-bit при работе с браузером Опера получил черный экран, система перезагрузилась. Вот ссылка на дамп памяти https://yadi.sk/d/hdp4Hxtg3TaAWa
    Сам разобраться не смог, вот сам скрин ошибки https://yadi.sk/i/wHRt5xlm3TaBne
    Пожалуйста, помогите разобраться.

    • einaare

      Здравствуйте!
      1. У вас какая-то нестандартная сборка системы или активация произведена активатором? при анализе дампа я обнаружил файл xNtKrnl.exe, к которому не смог загрузить символы. Наличие данного файла может говорить о переименовании ядра.
      2. Могли бы вы сделать полный дамп памяти системы? вот тут можно посмотреть как настроить: http://datadump.ru/windows-crash-dump/

      • Валерий

        Спасибо за ответ! Вас понял, только в настройках нет возможности установить полный дам памяти, т.е. есть только малый дамп и дамп памяти ядра. Сборка применялась Windows 7 SP1 х86-x64 by g0dl1ke 17.12.15 с уже встроенным в систему активатором. В поиске искал решение своей проблемы и понял, что это связано с ядром системы. Встречались и советы удалить программу Adguard, которая может быть источником подобных проблем. Программу эту удалил и пока все нормально. Возможно следует использовать сборку в которой исключены подобные проблемы, но пока подходящего ничего не нашел, т.к. многие сборки стали содержать проблемные обновления с начала 2018 года.

        • einaare

          в конце статьи сценарии с настройкой полного дампа, запускаете под админом. STOP 3B звучит как SYSTEM_SERVICE_EXCEPTION, поэтому может быть виновен любой _сторонний_ сервис (инсталлируемый ПО от мат. платы, антивирусом и прч.). В качестве общего решения (без анализа дампа), я бы порекомендовал запустить services.msc и просто пройтись по всем _сторонним_ сервисам, проанализировав их и (по возможности) отключив (свойства, тип запуска: отключена).. посмотреть на эффект. Относительно сторонних сборок: посоветовал бы вам избавиться от них вообще, и устанавливать MSDN образы... но тут выбор за вами :)

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

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