Как прочитать дамп падения Windows в WinDbg: инструкция по поиску причин BSOD

Откуда берется «черный экран смерти» и почему стоп-код не дает ответа

Начиная с обновления 24H2, привычный синий экран смерти в Windows уступил место строгой черной плашке. Разработчики Microsoft убрали пиксельный смайлик и QR-код, оставив на экране только текстовый код ошибки и имя сбойного файла. Однако суть происходящего не изменилась: операционная система продолжает внезапно уходить в перезагрузку, а смене подверглась лишь визуальная палитра.

Почему базовый стоп-код не раскрывает причину сбоя

Когда компьютер падает в критическую ошибку, первое порывистое действие пользователя — скопировать текст вида IRQL_NOT_LESS_OR_EQUAL в поисковую строку. Однако поисковики выдают либо общие советы, либо диаметрально противоположные рекомендации. Дело в том, что текстовый стоп-код представляет собой лишь признак того, что ядро зафиксировало критическую аномалию и остановило работу. Он показывает сам факт невозможности дальнейшего выполнения кода, но молчит о конкретном виновнике. Один и тот же код может быть вызван некорректной работой сетевой карты, ошибкой памяти или сбоем стороннего софта.

Для наглядности приведу наиболее частые коды аварийной остановки:

• IRQL_NOT_LESS_OR_EQUAL (0xA): сбой происходит из-за попытки обращения к оперативной памяти на слишком высоком уровне прерывания. Обычно это указывает на ошибки в коде драйверов, хотя физический дефект модулей ОЗУ дает аналогичный результат.
• SYSTEM_SERVICE_EXCEPTION (0x3B): возникает при сбое во время исполнения системного вызова при переходе из пользовательского режима в режим ядра. Чаще всего причина кроется в стороннем драйвере.
• PAGE_FAULT_IN_NONPAGED_AREA (0x50): попытка запросить данные из несуществующей страницы памяти. Виновником выступает либо сбойный модуль драйвера, либо нестабильная планка памяти.
• WHEA_UNCORRECTABLE_ERROR (0x124): критический аппаратный сбой оборудования, требующий отдельного подхода к диагностике.

Заметить строгую закономерность по одному лишь текстовому коду невозможно. Без глубокого анализа аварийного дампа поиск причин превращается в гадание.

Где искать дамп памяти и как настроить WinDbg

В момент аварии Windows автоматически формирует аварийный минидамп — компактный файл, содержащий срез состояния ядра непосредственно перед падением. Эти файлы сохраняются в системном каталоге C:\Windows\Minidump и занимают всего несколько сотен килобайт.

Если указанный каталог отсутствует или пуст, в системе отключена запись аварийных дампа. Чтобы исправить это, открываем параметры системы по цепочке: «Дополнительные параметры системы» → «Загрузка и восстановление» → «Параметры». В выпадающем списке выбора отладочной информации необходимо задать значение «Малый дамп памяти» или «Автоматический дамп памяти». Учтите, что эта настройка работает только на будущее и не сможет восстановить данные прошлых падений.

Бывают ситуации, когда настройка активна, но файлы аварии все равно не формируются. Такое происходит при критических сбоях, когда ядро физически не успевает записать данные на диск, либо если на системном накопителе отключен файл подкачки. Кроме того, минидампы часто удаляются сторонними утилитами для очистки диска.

Пошаговый запуск и загрузка отладочных символов

Для чтения и расшифровки файлов дампов я использую официальный инструмент WinDbg, доступный в Microsoft Store. Инструмент бесплатен и прост в настройке, если следовать правильной последовательности действий:

1. Запустите WinDbg строго от имени администратора, иначе программа не получит доступ к системной папке с дампами.
2. Укажите путь к отладочным символам Microsoft. Для этого перейдите в меню File → Settings → Debugging settings → Symbol path и вставьте строку: srv*C:\symbols*https://msdl.microsoft.com/download/symbols. Отладочные символы необходимы для того, чтобы сопоставить внутренние адреса функций с их человекочитаемыми названиями.
3. Откройте нужный файл дампа через меню File → Open dump file. При первом запуске понадобится подождать пару минут, пока подгрузятся символы из сети. В последующие разы они будут браться из локального кэша C:\symbols.
4. В строке ввода команд наберите !analyze -v и нажмите Enter. Флаг -v обязателен, так как он включает вывод подробной отладочной информации.

Разбираем вывод !analyze -v: главные поля и параметры

В ответ на команду утилита выдаст подробный текстовый отчет. Нам потребуются всего несколько ключевых строк:

• BUGCHECK_CODE: шестнадцатеричный идентификатор ошибки, дублирующий стоп-код с экрана.
• BUGCHECK_P1 — BUGCHECK_P4: четыре аргумента ошибки, раскрывающие технические детали. Например, для кодов 0xA и 0xD1 первый параметр содержит адрес памяти, к которому было обращение, второй — уровень IRQL, третий определяет тип операции (0 — чтение, 1 — запись), а четвертый указывает на адрес вызвавшей инструкции. Если первый аргумент содержит значение 0000000000000000, произошла попытка обращения по нулевому указателю, а мусорные значения вроде ffffffffffffffff говорят о повреждении структуры памяти.
• IMAGE_NAME: имя исполняемого файла или драйвера, вызвавшего сбой. Это главный ориентир.
• MODULE_NAME: название модуля без расширения.
• PROCESS_NAME: имя процесса, работавшего в момент аварии. Если здесь указано имя стороннего приложения, а не системный процесс System, диагностику следует начинать с этой программы.
• FAILURE_BUCKET_ID: уникальный идентификатор вида 0x3B_c0000005_somefilter!Unknown, по которому удобно искать аналогичные случаи на специализированных форумах.

Если значения IMAGE_NAME и FAULTING_MODULE расходятся, приоритет при анализе всегда следует отдавать полю IMAGE_NAME.

Анализируем стек вызовов и сторонние модули

Самая ценная часть отчета — стек вызовов (Call Stack), отражающий хронологию выполнения функций непосредственно перед аварией. Для просмотра стека используются следующие команды:

• k — вывод базового стека вызовов;
• kb — отображение стека с первыми тремя аргументами для каждой функции;
• kn — вывод стека с нумерацией фреймов;
• kv — наиболее детальный вариант с отображением трап-фреймов и точек перехода.

Стек читается снизу вверх: самая нижняя строчка соответствует началу цепочки вызовов, а самая верхняя — моменту возникновения ошибки. Если в одной из строк вместо названия функции указан чистый шестнадцатеричный адрес, это говорит о работе стороннего драйвера (например, видеокарты NVIDIA, сетевого адаптера Realtek или ПО для периферии), для которого у WinDbg нет отладочных символов.

Чтобы выяснить принадлежность некорректного адреса, используйте команду ln адрес. Утилита покажет ближайшие известные функции и имя модуля-владельца. Из других полезных команд отмечу .bugcheck (краткая выжимка ошибки), vertarget (время аптайма системы до падения) и !lmi имя_модуля (подробные данные о файле, включая дату сборки).

Обратите внимание: минидамп содержит только регистры и стек. Команды глубокого анализа процессов вроде !process или !pool требуют создания полного дампа памяти ядра.

Почему строка Probably caused by часто ошибается

Главная ловушка WinDbg заключается в итоговой строчке Probably caused by. Многие пользователи воспринимают указанный там модуль как окончательный вердикт, но это лишь автоматическое предположение анализатора, которое регулярно оказывается ошибочным.

Распространенный случай — указание на файл Wdf01000.sys. Данный модуль представляет собой системный фреймворк Windows Driver Framework, через который работает огромное число драйверов. Сам фреймворк исправен, а падение происходит из-за некорректных данных от стороннего драйвера. Аналогичная ситуация складывается с системным ядром ntoskrnl.exe или ntkrnlmp.exe.

Автоматический вердикт ошибается и в случаях, когда аварию вызвало железо — перегрев, нестабильный разгон или сбоящая оперативка. Ядро падает на случайном модуле, оказавшемся в памяти, и анализатор ошибочно помечает его виновным.

Это подтверждается тестовыми экспериментами: при искусственном провоцировании сбоя через драйвер myfault.sys анализатор WinDbg выдает вердикт Probably caused by : memory_corruption, хотя оперативка полностью исправна. Однако строчкой выше утилита честно сообщает: symbols could not be loaded for myfault.sys. Строка об отсутствии символов часто дает более точную наводку, чем итоговый вывод.

Поиск истинного виновника через IMAGE_NAME и даты сборки

При разборе поля IMAGE_NAME ориентируйтесь на следующую классификацию:

• Сторонние драйверы (nvlddmkm.sys, rtwlane.sys, atikmdag.sys): реальные кандидаты на виновников сбоя.
• Системные файлы (ntoskrnl.exe, hal.dll, Wdf01000.sys): в 99% случаев являются ложным следом.
• Файлы стороннего ПО (антивирусы, утилиты разгона, драйверы периферии): частая причина несовместимости.

Определив сторонний драйвер, выполните команду lmvm имя_драйвера (например, lmvm nvlddmkm), чтобы узнать точную дату его сборки. Старые драйверы — частая причина падений после крупных обновлений Windows (например, при переходе на 25H2). Драйверы сетевых карт или Wi-Fi, собранные за пару лет до обновления OS, могут вызывать постоянные BSOD, хотя сама система считает их актуальными.

Анализ аппаратных сбоев: разбор ошибки WHEA_UNCORRECTABLE_ERROR

Код 0x124 (WHEA_UNCORRECTABLE_ERROR) стоит обособленно. Расшифровываясь как Windows Hardware Error Architecture, он сигнализирует о неустранимой аппаратной ошибке оборудования, зафиксированной процессором.

Значение первого аргумента 0 означает фатальный сбой Machine Check Exception, при котором система мгновенно останавливает работу. Значение 1 указывает на исправленную аппаратную ошибку. В минидампах подробная структура WHEA_ERROR_RECORD часто отсутствует, поэтому WinDbg фиксирует факт сбоя, но не даёт детализации.

Поиск сбойного ядра или памяти через Просмотр событий

Чтобы получить исчерпывающие данные по ошибке 0x124, обратитесь к системному журналу Windows:

1. Откройте «Просмотр событий» (Win + R → eventvwr.msc).
2. Перейдите в раздел «Журналы Windows» → «Система».
3. Выполните фильтрацию по источнику WHEA-Logger (события с ID 17, 18, 46, 47).

В описании события найдите строки Error Type и Processor APIC ID. Параметр Error Type указывает на характер поломки: Cache Hierarchy Error говорит о проблемах с кэшем процессора, Translation Lookaside Buffer Error — о сбое буфера трансляции, а Bus/Interconnect Error — о проблемах шины связей.

Поле Processor APIC ID содержит номер логического ядра. Если при сериях падений номер ядра постоянно меняется, проблема кроется в нестабильности памяти или питания. Если же ошибка из раза в раз возникает на одном и том же APIC ID, виновником является конкретное ядро процессора. При наличии разгона его необходимо полностью отключить перед дальнейшими шагами.

Driver Verifier: как заставить сбойный драйвер выдать себя

Если дампы показывают только системные файлы, а падения продолжаются, применяется инструмент стресс-тестирования Driver Verifier. Он принудительно подвергает драйверы жестким проверкам, вызывая контролируемый BSOD при малейшем нарушении с точным указанием сбойного файла.

Внимание: утилиту следует использовать с осторожностью. Если сбойный драйвер инициализируется при старте системы, ПК войдет в циклическую перезагрузку.

Порядок безопасной работы с Driver Verifier:

1. Обязательно создайте точку восстановления системы.
2. Запустите verifier от имени администратора и выберите «Создать нестандартные параметры».
3. Отметьте для проверки только сторонние драйверы (драйверы не от Microsoft).
4. Используйте ПК в обычном режиме до возникновения сбоя.
5. После падения расшифруйте свежий дамп памяти — в нем будет указан точный виновник.

Для отключения проверок выполните команду verifier /reset и перезагрузите ПК. Если система зациклилась при загрузке, зайдите в среду восстановления и выполните отмену проверок через командную строку. Чтобы обезопасить себя заранее, при настройке можно активировать режим verifier /bootmode resetonbootfail, который автоматически сбросит проверки при неудачном старте.

Как быстро отличить программный сбой от аппаратной поломки

Свожу основные признаки в наглядный диагностический чек-лист:

• Строгая повторяемость: сбой происходит при конкретном действии (запуск игры, вставка накопителя, выход из спящего режима). Причина: драйвер или софт.
• Случайный характер: падения происходят в разное время с отличающимися стоп-кодами. Причина: аппаратные неисправности (часто неисправная ОЗУ).
• Наличие событий WHEA-Logger: гарантированный аппаратный сбой оборудования.
• Сбой после обновления: некорректный драйвер или обновление программы.
• Сбой после изменения частот: нестабильность разгона процессора или профилей XMP/EXPO памяти.
• Дампы указывают на разные сторонние модули: нестабильность оперативной памяти, роняющая случайные процессы.

Пошаговый план действий после расшифровки дампа

На основе полученных данных выберите соответствующий сценарий устранения проблемы:

1. Выявлен конкретный драйвер: откройте «Диспетчер устройств» и выполните откат на предыдущую версию. Если кнопка неактивна, удалите драйвер с помощью утилит очистки и установите актуальную версию с официального сайта производителя оборудования.
2. Подозрение на оперативную память: отключите профили XMP/EXPO в BIOS и выполните не менее 3–4 проходов утилитой MemTest86.
3. Ошибки WHEA по конкретному ядру: сбросьте разгон, проверьте температурный режим процессора, обновите BIOS материнской платы. При сохранении сбоев обратитесь в сервисный центр.
4. Неопределенные системные дампы: активируйте Driver Verifier, предварительно создав точку восстановления.

Итоги и выводы

Текстовый стоп-код на экране не дает точного ответа о причинах падения системы, являясь лишь внешним симптомом. Полная диагностика занимает несколько минут при использовании WinDbg, правильной настройке путей к символам и выполнении команды !analyze -v.

Не следует слепо доверять строке Probably caused by, так как она часто указывает на системные прослойки вроде Wdf01000.sys или ядро OS. При коде ошибки 0x124 сразу переходите к анализу журнала WHEA-Logger в «Просмотре событий» для поиска неисправного компонента.

Делитесь в комментариях своим опытом разбора аварийных дампов: с какими нестандартными случаями вам приходилось сталкиваться и насколько автоматические вердикты отличались от реальных причин?

Источник: habr.com