#Когда применима инструкция и что означает сбой
Минидамп — небольшой файл отладки, который Windows иногда создаёт после аварийной остановки. Его анализ через WinDbg помогает найти код ошибки и задействованные модули, но не гарантирует автоматического определения «виновного драйвера». Инструкция для Windows 11 с уже произошедшим BSOD.
#Как отличить возможные причины
| Возможная причина | Как узнать | Что делать |
|---|---|---|
| Файл аварии сохранилсяWindows смогла записать сведения о сбое на диск. | В %SystemRoot%\Minidump есть .dmp с датой падения. | Сделайте копию и откройте в WinDbg. |
| Минидамп отсутствуетВывод дампа мог быть выключен, недостаточно места или диск был недоступен. | Папки нет или она пуста несмотря на BSOD. | Проверьте настройки записи и доступность системного диска. |
| Имя модуля вводит в заблуждениеСтек ошибок иногда содержит пострадавший драйвер, а не первопричину. | В разных дампах указаны разные библиотеки. | Сопоставляйте события, параметры StopCode и повторяемость. |
#Пошаговая диагностика и действия
- Зафиксируйте точный код остановки и исходные условияПри следующем случайном сбое сфотографируйте STOP-код, возможное имя файла .sys и запишите время. Для сценария «необходимо изучить минидамп Windows 11 после BSOD» отметьте, что было подключено или запущено за 1–2 минуты до ошибки. Не пытайтесь вызвать десятки новых аварий: это риск потери несохранённых данных. После удачной загрузки нажмите Win+R, введите winver, перепишите версию Windows 11 и номер сборки. Если экран вообще не показывает код, зафиксируйте поведение и продолжайте проверку по журналам.
- Сверьте запись об аварии, а не только «Критическую ошибку»Нажмите Win+R, введите eventvwr.msc и откройте «Журналы Windows» → «Система». В правой панели выберите «Фильтр текущего журнала» и укажите идентификаторы 41, 1001, 6008, если записи присутствуют. Дважды щёлкните запись времени сбоя, перепишите источник и текст. Kernel-Power 41 означает неожиданный перезапуск, но не называет виновника; событие BugCheck 1001 и сохранённый дамп полезнее. Если дампа нет, не считайте это доказательством исправности.
- Найдите минидамп и сохраните оригиналНажмите Win+R, введите %SystemRoot%\Minidump, затем Enter. В Проводнике переключите отображение на «Таблица», найдите файлы .dmp с датой нужного сбоя. Скопируйте файл в отдельную папку пользователя и работайте с копией; не редактируйте оригинал и не публикуйте дамп в общий доступ. Если папки нет, переходите к настройке записи.
- Проверьте настройки записи минидампов без изменения чужих параметровНажмите Win+R, введите sysdm.cpl → «Дополнительно» → «Загрузка и восстановление» → «Параметры». Найдите список «Запись отладочной информации». Для последующих сбоев можно выбрать «Малый дамп памяти (256 КБ)», если доступно и есть полномочия администратора. Запишите прежний выбор перед изменением; убедитесь, что системный диск имеет свободное место. Это не создаст дамп задним числом.
- Установите официальный WinDbgОткройте страницу Microsoft Learn «Install WinDbg» и выберите Microsoft Store, прямую установку или пакетный менеджер Windows, если разрешено политиками ПК. В обычном терминале допустима команда winget install Microsoft.WinDbg; приложение может попросить подтверждение условий. Если winget недоступен, воспользуйтесь официальной установкой; не скачивайте «анализаторы» с неизвестных сайтов.
- Откройте копию дампа и дождитесь символовЗапустите WinDbg → File → Open dump file, укажите скопированный .dmp. Дождитесь загрузки данных и символов; если отладчик запрашивает настройку символов, используйте документацию Microsoft и доверенный сервер символов. Ошибка символов может мешать расшифровке, но не означает, что дамп вредоносный.
- Выполните анализ и разберите основные поляВ командном поле WinDbg наберите !analyze -v и нажмите Enter. Перепишите BUGCHECK_CODE, параметры, MODULE_NAME и IMAGE_NAME, если они присутствуют. Значение Probably caused by — гипотеза анализа, а не гарантированная причина. Для просмотра загруженных модулей можно применять lm; при сомнениях передайте отчёт инженеру.
- Сравните несколько аварий и действие пользователяЕсли файлов несколько, откройте их по одному и сравните одинаковый ли код и модуль. Уточните у пользователя время, событие из журнала и что происходило перед падением. Если каждый раз виновником называют системное ядро, это не аргумент для замены ntoskrnl.exe: проверьте драйверы, память и оборудование по совокупности данных.
- Проведите контролируемую проверку именно этого сценарияПосле каждого безопасного изменения выполните одну штатную перезагрузку и проверьте сценарий «необходимо изучить минидамп Windows 11 после BSOD» только если повторение не опасно для накопителя или оборудования. Перед проверкой сохраните документы; записывайте единственное изменение и результат, а не меняйте пять параметров сразу. Если вновь появляется BSOD, прекратите испытания, сохраните код и время и перейдите к диагностике у изготовителя.
#Команды, упомянутые в инструкции
Выполняйте приведённые команды только в указанной среде и с необходимыми правами. Команды не заменяют проверку симптома, и результаты могут зависеть от версии Windows.
Windows · PowerShellКоманда
Обычный PowerShell или Терминал с доступным winget; устанавливает официальный WinDbg, может запросить согласие/права. Если политика организации запрещает — не запускать.
winget install Microsoft.WinDbgТекстКоманда
Командное поле внутри WinDbg после открытия дампа, НЕ cmd/PowerShell. Выводит подробный анализ остановки. Ничего в системе не меняет.
!analyze -v#Как убедиться в результате
Успех диагностики — получены код остановки, параметры и сопоставимые с моментом сбоя события; дальнейшее исправление зависит от достоверно выявленной причины. Запуск WinDbg сам по себе не исправляет Windows и не удаляет BSOD.