Проблема
Вы работаете, играете или настраиваете сервер, и вдруг синий экран на пару секунд и перезагрузка. Windows любезно сообщает: «Мы собрали информацию и перезагрузимся». И всё. Никаких объяснений. А через час снова.
Многие в панике начинают переустанавливать Windows, менять железо наугад или несут компьютер в сервис с диагнозом «он у меня сыпется». Но на самом деле Windows каждый раз сохраняет улику минидамп памяти. Это как чёрный ящик самолёта. Надо только уметь его прочитать.
Решение
Мы настроим систему, чтобы она не перезагружалась сразу (успеем записать код ошибки), научимся находить и анализировать дампы двумя способами:
- Быстрый и простой с помощью программы BlueScreenView (для новичков).
- Продвинутый и точный с помощью WinDbg (для тех, кто хочет копать глубже).
И главное разберём реальный пример с расшифровкой, чтобы вы поняли логику.
Пошаговая инструкция
Шаг 0. Подготовка: включаем запись дампов и отключаем автоперезагрузку
По умолчанию Windows после BSOD быстро перезагружается, чтобы вы не паниковали. Но нам нужна улика. Давайте настроим.
Для Windows 10/11:
- Нажмите
Win + Pause/Break(или правой кнопкой на «Этот компьютер» «Свойства»). - Слева выберите «Дополнительные параметры системы».
- Вкладка «Дополнительно», раздел «Загрузка и восстановление» →кнопка «Параметры» .
- В открывшемся окне:
Теперь при следующем BSOD компьютер зависнет на синем экране с грустным смайликом и кодом ошибки. Вы сможете его сфотографировать, а главное в папке C:\Windows\Minidump появится файл с расширением .dmp .
Шаг 1. Где лежат дампы?
Все минидампы хранятся в папке:
C:\Windows\MinidumpТакже может быть полный дамп C:\Windows\MEMORY.DMP, но для начала нам хватит минидампов — они маленькие и быстрые в анализе .
Шаг 2. Анализ с помощью BlueScreenView (для новичков)
Самый простой способ — скачать бесплатную утилиту BlueScreenView от NirSoft . Она не требует установки (portable-версия).
Что делаем:
- Скачиваем с официального сайта (https://www.nirsoft.net/utils/blue_screen_view.html).
- Запускаем (от имени администратора, чтобы увидеть все дампы).
- Программа автоматически найдёт все дампы в папке Minidump и покажет их списком .
Как читать:
- Верхняя панель список BSOD (дата, код ошибки, количество).
- Нижняя панель драйверы, загруженные в момент краша.
- Красным цветом подсвечены те драйверы, которые, вероятно, вызвали сбой .
- Самый важный столбец «Caused by Driver» (Вызвано драйвером). Если там написано, например,
nvlddmkm.sys— виновата видеокарта NVIDIA. Еслиntoskrnl.exeэто ядро Windows, но оно редко бывает первопричиной, чаще это «посредник», а настоящий виновник нужно искать среди сторонних драйверов .
Полезные фишки:
- Нажмите F8 откроется окошко с синим экраном в том виде, как он был .
- Двойной клик по дампу подробная информация: параметры ошибки, стек вызовов, адрес.
Шаг 3. Продвинутый анализ с WinDbg (для точности)
Иногда BlueScreenView показывает на ntoskrnl.exe, и непонятно, кто реально виноват. Тогда нужна тяжёлая артиллерия — отладчик WinDbg от Microsoft .
Установка:
- Скачайте WinDbg из Microsoft Store или в составе Windows SDK .
- Установите только отладчик (не всё SDK).
Настройка символов:
Чтобы WinDbg показывал понятные имена функций, а не кучу цифр, нужно указать путь к серверу символов Microsoft. В WinDbg нажмите Ctrl+S и вставьте:
text
SRV*C:\Symbols*http://msdl.microsoft.com/download/symbolsЭто загрузит отладочные символы по запросу .
Анализ дампа:
- Откройте WinDbg.
-
File→Open Crash Dump(или перетащите файл.dmpиз папки Minidump в окно WinDbg). - После загрузки введите команду:text!analyze -vи нажмите Enter .
- Через несколько секунд (может подгружаться символы) вы увидите подробный анализ.
Что ищем в выводе WinDbg:
-
BUGCHECK_CODE код ошибки (например,
0x116). - BUGCHECK_STR строка с кодом и доп. параметрами.
- PROCESS_NAME имя процесса, который крашился.
- MODULE_NAME и IMAGE_NAME имя модуля (драйвера), который признан виновным. Это самое главное!
- STACK_TEXT стек вызовов в момент ошибки. Часто там видна цепочка, приведшая к краху.
Шаг 4. Реальный пример из жизни (разбор дампа)
Давайте разберём реальный случай с форума Microsoft Q&A, где пользователь мучился с BSOD несколько месяцев .
Исходные данные:
У пользователя постоянно вылетали синие экраны с разными кодами. Он прислал несколько дампов.
Анализ первого дампа (072521-11031-01.dmp):
- Код: 0x7A KERNEL_DATA_INPAGE_ERROR (ошибка чтения данных с диска в память).
- Процесс: MsMpEng.exe (защитник Windows).
- NTSTATUS: 0xC000009C STATUS_DEVICE_DATA_ERROR (ошибка данных на диске, плохие блоки).
Анализ второго дампа (072521-5515-01.dmp):
- Код: 0x154 UNEXPECTED_STORE_EXCEPTION (ошибка при работе с памятью/диском).
- Процесс: MemCompression.
- Ведро ошибки: hardware_disk.
Третий дамп (072421-16171-01.dmp):
- Снова 0x154 и снова hardware_disk.
Вывод специалиста:
«Вам надо очень срочно подумать о замене жёсткого диска. Сейчас сохраните все что вам ценно на внешний диск» .
Что произошло:
Несмотря на разные коды ошибок, все они указывали на одно проблемы с диском. Система не могла прочитать данные с диска (битые сектора), и это вызывало синие экраны. Пользователь мог бесконечно переустанавливать Windows, менять драйверы, но проблема решилась только заменой диска .
Мораль: разные коды BSOD могут указывать на одну и ту же железную проблему. Важно смотреть не только код, но и контекст.
Шаг 5. Расшифровка популярных кодов ошибок
Чтобы быстрее ориентироваться, вот шпаргалка по частым ошибкам :
Итог: шпаргалка по диагностике BSOD
| Шаг | Действие | Результат |
|---|---|---|
| 0 | Настроить систему: отключить автоперезагрузку, включить запись мелких дампов | Появятся файлы в C:\Windows\Minidump |
| 1 | Скачать BlueScreenView | Быстрый просмотр и определение виновного драйвера по красной подсветке |
| 2 | Если нужно точнее WinDbg + команда !analyze -v | Полный отчёт с указанием модуля и стека |
| 3 | Посмотреть на процесс и код ошибки | Понять, проблема в драйвере, диске или памяти |
| 4 | Принять меры: обновить драйвер, заменить диск, проверить память | Устранить причину |
Заключение
Синий экран это не конец света, а просто способ Windows сказать: «Я сломалась, вот отчёт, чини». Главное не паниковать и не переустанавливать систему наугад. Возьмите дамп, откройте его BlueScreenView или WinDbg, найдите виновный файл и в 90% случаев причина станет очевидной.
И помните: если дампы стабильно указывают на ntoskrnl.exe, а сторонних драйверов нет проверяйте железо (оперативку, диск, перегрев). Ядро Windows редко врёт, но часто оказывается жертвой обстоятельств .
