Файл дампа. Два способа анализа дампа памяти.

Чтобы исправить синий экран смерти необходимо выявить причину его появления. Для этого нужно проанализировать аварийный файл дампа памяти.Файл дампа. Способы анализа Анализ аварийного дампа можно провести различными способами. Об этом как раз и поговорим в этой статье.

Что нужно знать, про файл дампа?

В предыдущей статье на сайте мы уже писали про причины, которые чаще всего приводят к синему экрану смерти. Также показали как правильно настроить создание аварийных дампов памяти и рассказали где хранится этот самый файл дампа. Мельком коснулись того, что по стоп коду и по информации из дамп файла можно путём анализа точнее выяснить причину приведшую к BSOD.
Осталось узнать как и с помощью чего можно проанализировать информацию из дамп файла. Рассмотрим несколько способов, включающих как инструмент анализа от самих разработчиков Windows так и сторонние инструменты.

Анализ дамп файла с помощью Microsoft Kernel Debugger.

Microsoft Kernel Debugger - специальная утилита для анализа крэш дампов. Скачать саму утилиту, а также необходимые для её работы компоненты можно с сайта Microsoft - Debugging tools. Версия пакета Debugging Tools for Windows должна соответствовать разрядности операционной системы. Подробно про то где и как скачать эту утилиту писал тут.
Вместе с самим отладчиком необходимо ещё скачать набор отладочных символов - Debugging Symbols. Набор символов, также различается для каждой версии Windows, включая и по разрядности. Таким образом, для 32-х разрядной Windows 7 необходимо скачать пакет символов Windows 7 x32, а для 64-х битной Windows 7 набор символов Windows 7 x64. Таким же образом нужно выбирать набор символов и для других версий Windows (widows 10, XP и т.д.). Нужный набор символов также можно скачать в самом отладчике, но об этом ниже.
После установки утилиты и набора отладочных символов, можно запустить сам отладчик. После запуска необходимо в его настройках указать ему путь до отладочных символов. Для этого:
Нажмите на кнопку FileSymbol File Path...
Далее нажмите кнопку Browse и укажите папку куда сохранили набор символов.
Скачать самую новую версию символов можно с помощью самой утилиты. Для этого в поле FileSymbol File Path... введите:
SRV*C:\symbols*http://msdl.microsoft.com/download/symbolsзагрузка отладочных символов для WinDBG с сервера MicroSoft
Далее нажмите на FileSave workspace и затем нажмите на ОК.
Таким образом утилита запросит информацию об отладочных символах через интернет напрямую с сервера Microsoft.
Для того, чтобы приступить к анализу нажмите на File > Open Crash Dump… и укажите требуемый файл дампа памяти (малый дамп памяти).
Система проведёт анализ дампа и по результатам выдаст возможную причину ошибки.Результаты анализа дамп файла в WinDBG
Кликнув по гиперссылке !analyse-v откроется более расширенная информация по ошибке.
Завершить отладку можно с помощью пункта меню Debug > Stop Debugging.

Анализ файла дампа с BlueScreenView

BlueScreenView это бесплатная утилита для анализа файла малого аварийного дампа памяти. Данная утилита имеет поддержку русского языка. Основным плюсом данной программы является то, что для её работы не нужно скачивать отладочные символы. Это делает эту утилиту полностью автономной и независимой. Еще одним плюсом данной программы является наличие портабельной версии, то есть версии, которую не нужно устанавливать в систему. Автором программы является Nier Sofer. Скачать можно с официального сайта автора. Портабельную версию программы можно скачать по ссылке на официальной странице, в названии которого, в скобках указано in Zip file.версии программы BlueScreenView для скачивания При скачивании важно учитывать разрядность вашей ОС.
Пролистав чуть ниже можно скачать файл русификации - BlueScreenView_lng.ini, который нужно просто закинуть в папку с самой программой. Я подготовил для скачивания программу с уже настроенным языком. Вот прямые ссылки:

А теперь непосредственно про процедуру анализа.

Как провести анализ файла дампа с BlueScreenView?

После запуска программа сразу сканирует стандартную директорию хранения файла дампа - %SystemRoot%\Minidump. Директорию можно изменить в дополнительных параметрах программы. Интерфейс окна программы условно можно поделить на 3 области:

  • Верхняя область кнопок меню
  • Средняя область со списком файлов дампов
  • Нижняя область со списком драйверов

интерфейс программы BlueScreenView
Данные анализа выводятся в табличном виде. Перечислю наиболее важные из столбцов средней области интерфейсного окна программы (в скобках наименование из англ. версии):

  • Текст ошибки (Bug Check String). Здесь выводится описание ошибки согласно классификации MicroSoft. В нашем примере это DRIVER_IRQL_NOT_LESS_OR_EQUAL.
  • Код ошибки (Bug Check Code). Выводится СТОП-код ошибки - 0x000000d1
  • Драйвер причины (Caused By Driver). Отображает наименование драйвера либо модуля, который вероятнее всего вызвал ошибку. Заметьте, это 100% виновник ошибки, а лишь вероятный. В нашем примере это E1G6032E.sys
  • Адрес причины (Caused By Address). Отображает драйвер и сразу после адрес инструкций, вызвавших сбой. У нас это E1G6032E.sys+9ef530</li>
  • Адрес аварии (Crash Address). Адрес по которому случилась ошибка. В нашем случае ntoskrnl.exe+1509a0.

Теперь перечислю наиболее важные столбцы из нижней области:

  • Имя файла (File name). Указывается наименование драйвера либо модуля
  • Адрес в стеке (Address In Stack). Выводится адрес памяти драйвера из стека памяти.
  • Описание файла (File Description).
  • Версия файла (File Version). Отображается версия файла драйвера.

Для анализа выделяем нужный файл дампа в средней области окна утилиты. При выделении нижняя область сразу заполняется данными. Смотрим в таблице данные из основных столбцов, которые я привёл выше. В нижней области окна вероятные проблемные драйвера либо модули выделяются красным цветом. Редко, бывают случаи, когда указанный программой в средней области окна драйвер не является источником BSOD ошибки. В таких случаях, среди подсвеченных красным цветом ниже, проблемных драйверов, наверняка присутствует истинный источник синего экрана смерти. В моём случае это: E1G6032E.sys и ntoskrnl.exe. Кстати, оба являются довольно таки распространёнными причинами BSOD.
Если найденные программой источники ошибки вам ни о чём не говорят, то можно просто в поисковике ввести наименование проблемных драйверов и там наверняка найдёте как их побороть.
Для более точного определения проблемных драйверов и модулей можно воспользоваться несколькими способами анализа. Благо в данной статье мы разобрали два наиболее популярных. Следите за публикациями и в дальнейшем выйдет ещё статья про анализ дампов.

Закладка Постоянная ссылка.

Форма подписки по e-mail:

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

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

Я согласен(а) с обработкой персональных данных и политикой конфиденциальности