Синий экран смерти. Анализ и расшифровка дампа памяти при BSOD
Windows вывалился в синий экран смерти. Что делать? Однозначного ответа на этот вопрос нет, так как вариантов лечения и расшифровки синих экранов смерти великое множество. Попробую рассказать как выявить причину синего экрана и диагностировать ошибку с вероятностью, близкой к 100%, а гадание оставим синоптикам. На прошлой неделе ремонтировал компьютер на котором вылетал синий экран смерти с разными ошибками, чаще всего BAD_POOL_CALLER — stop 0x000000c2. Диагностируется данная ошибка довольно сложно, на его примере и попытаюсь рассказать как узнать причину возникновения по синего экрана смерти. В процессе диагностики не обойтись без анализа специального файла minidump (дамп памяти) системы. Такие файлы создаются каждый раз после сбоя работы системы и содержат информацию о том, что к этому привело. Обычно все файлы minidump при BSOD сохраняются в папку C:\Windows\Minidump. Кроме того, имя файла содержит текущую дата его создания, чтобы не путаться когда возникла ошибка, если файлов много. Проверьте, включено ли на вашем компьютере создание файлов minidump при сбое системы.
Анализ дампа памяти. Расшифровываем minidump.
Нам понадобится установить Debugging Tools for Windows и скачать утилиту непосредственно для расшифровки файла дампа kdfe.cmd Распаковываем скрипт kdfe.cmd и кладем его непосредственно в корень диска диска C:\ или создаем каталог C:\dump. Тут уж как вам удобнее. В командной строке пишем: Выведется список всех минидампов, из папки C:\Windows\Minidump\ и скрипт предложит указать какой именно дамп будем анализироваться, либо можно самостоятельно выбрать требуемый дамп при запуске скрипта: На мой взгляд первый вариант удобнее. Пример того что выдал скрипт при анализе одного из дампов памяти: Еще одно доказательство что лучше избавляться от этих дебильных Амиго и майлру агентов. Таким же образом можно выявить и другие ошибки, приводящие к BSOD. Существует еще одна интересная утилитка BlueScreenView, часто встречается на загрузочных флешках-реаниматорах, о которой я уже писал ранее на страницах блога, но на мой взгляд менее понятная для новичков.
Если считаете статью полезной,
не ленитесь ставить лайки и делиться с друзьями.
Комментариев: 8
Спасибо за детальное описание. Помогло. Не запускается kdfe.cmd , пишет — «Ошибка в синтаксисе команды» Просто надо изменить эту утилиту.Открыть с помощью блокнота и изменить путь Debudding Tools.Там на какой то строке меняешь в двух-четырех местах вместо program files как у себя, например program files(x86). Не помогло так как в cmd не находит выше написанное У меня тоже была подобная ошибка при запуске Сам догадался посмотреть сценарий и изменить
строку в файле kdfe.cmd Вот что надо изменить и будет работать: Я в таких случаях переустанавливал, пока диск не истерся до нечитаемого состояния. Потом линуха поставил. 98 % летит видяшник , подключитесь к встроенной в мамку.. и станет ясно ! удачи ..мужики ! Для начала, надо переписать саму ошибку, то есть например хх. 57 или что то типа того, бывают такие поломки как, полностью выход из строя жесткого диска, в таком случае никакой дамп вы уже не прочтете, у меня так было, поломка ssd диска, там было что то типа хх. 069, благо был рядом второй комп, нашел в инете расшифровку с разными ошибками и поломками, и так быстро установил причину синего экрана, после установки другого диска с системой, пока ssd был в ремонте, проблема исчезла сама собой. Источник
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 отображает список обнаруженных в системе дампов памяти. Здесь я перечислю только основные столбцы верхнего фрейма программы:
| Столбец | Назначение |
|---|---|
| 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, который опирается на адреса памяти, но никак не зависит от наличия/отсутствия символов системы/модулей/драйверов. Символы нужны для дополнительной информации по внутренним функциям.
Анализ результатов
Собственно, вкратце, общий алгоритм поиска причины сбоя следующий: Источник
Открываем дампы памяти DMP
Варианты открытия DMP
Расширение DMP зарезервировано за файлами дампов памяти: снимков состояния RAM в определённый момент работы системы или отдельного приложения, которые нужны разработчикам для последующей отладки. Такой формат используют сотни видов ПО, и рассмотреть их все в объёмах данной статьи невозможно. Наиболее же часто встречающийся тип DMP-документа – так называемый малый дамп памяти, где записаны подробности сбоя системы, который привёл к появлению синего экрана смерти, потому на нём и сосредоточимся.
Способ 1: BlueScreenView
Небольшая бесплатная утилита от разработчика-энтузиаста, основной функцией которой является предоставление возможности просмотра DMP-файлов. Не нуждается в установке на компьютер – достаточно распаковать архив в любое подходящее место.
- Для открытия отдельного файла нажмите на кнопку с иконкой программы на панели инструментов.
В окне «Advanced Options» отметьте чекбокс «Load a single Minidump File» и нажмите «Browse».
С помощью «Проводника» перейдите к папке с DMP-файлом, выделите его и нажмите «Открыть».
По возвращении в окно «Advanced Options» нажмите «ОК».
Утилита BlueScreenView рассчитана на продвинутых пользователей, потому её интерфейс может показаться сложным для новичка. Кроме того, доступна она только на английском языке.
Способ 2: Microsoft Debugging Tools for Windows
В составе среды разработки Windows SDK распространяется инструмент для отладки, который называется Debugging Tools for Windows. Приложение, рассчитанное на разработчиков, способно открывать в том числе и DMP-файлы.
- Для экономии места можно выбрать только Debugging Tools for Windows, отметив соответствующий пункт в процессе загрузки компонентов.
Запустить утилиту можно через «Пуск». Для этого откройте «Все программы», выберите «Windows Kits», а затем — «Debugging Tools for Windows».
Для запуска программы используйте ярлык «WinDbg».
Внимание! Для открытия DMP-файлов используйте только x64- или x86-версии дебаггера!
Утилита Debugging Tools for Windows ещё более сложная, чем BlueScreenView, и тоже не имеет русской локализации, однако предоставляет более подробную и точную информацию.
Заключение
Как видим, основную сложность при открытии DMP-файлов составляют сами программы, рассчитанные больше на специалистов, чем на рядовых пользователей.