Исправление синего экрана (BSoD) в Windows

Краткое содержание

Что такое синий экран и почему он появляется
Основные причины BSoD
Типы дампов и как их включить
Подробное руководство по WinDbg: установка, настройка символов, базовый анализ
Быстрая альтернатива: BlueScreenView
Чек-листы, SOP и шаблоны отчётов для инцидента
Когда инструменты не помогут и что делать дальше

Что такое синий экран ошибки

Синий экран — это экран аварийной остановки Windows. Система обнаружила критическую ошибку и завершила работу, чтобы предотвратить повреждение данных. Экран показывает код проверки ошибок (BugCheck) и технические данные, которые нужны для диагностики.

Определение в одну строку: BSoD (Blue Screen of Death) — системная авария Windows с дампом памяти и кодом ошибки.

Почему возникает синий экран

Причины варьируются, но чаще всего это:

Аппаратные сбои: память, диск, питание
Драйверы: устаревшие, некорректные или плохо написанные
Программное обеспечение с низким уровнем доступа (антивирусы, системные утилиты)
Перегрев или нестабильный разгон (overclocking)
Повреждённые системные файлы или ошибки памяти

Важно: код ошибки синий экрана даёт более конкретную подсказку о проблеме. Не угадывайте — анализируйте дамп.

Виды дампов и где их искать

Windows может сохранять несколько типов дампов. Понимание форматов ускоряет поиск причины.

Минидамп (minidump) — небольшой файл с основными параметрами, часто достаточен для первичной диагностики. Путь: C:\Windows\Minidump
Полный дамп (memory.dmp) — полный снимок оперативной памяти, больше данных, больше времени на анализ. Путь: C:\Windows\memory.dmp

Если у вас нет дампов, включите их в системных свойствах — “Параметры загрузки и восстановления” → “Запись отладочной информации” → выбрать тип дампа.

Важно: минидампы быстрее анализировать и обычно дают достаточно информации для определения проблем с драйверами и типичных ошибок.

Быстрый план действий при появлении BSoD

Зафиксируйте код ошибки и строку Bug Check. Сделайте фотографию экрана, если BSoD появляется редко.
Перезагрузите систему и сохраните файл дампа (minidump) из C:\Windows\Minidump или memory.dmp.
Используйте BlueScreenView для быстрой идентификации подозреваемого драйвера.
При необходимости используйте WinDbg для глубокого анализа с символами.
Примените исправления: обновление/откат драйверов, проверка памяти и диска, отключение разгона.
Если исправление не помогло — подготовьте отчёт и откат к последней стабильной конфигурации.

Как установить WinDbg (Debugging Tools for Windows)

WinDbg входит в состав Windows SDK. Ниже — шаги по установке.

Параметры установки Windows 10 SDK (опции)

Перейдите на страницу загрузки Windows 10 SDK.
Нажмите “Download the Installer”. Скачайте и запустите инсталлятор.
В установщике выберите опцию Install the Windows Software Development Kit.
На странице компонентов снимите все флажки, кроме “Debugging Tools for Windows”.
Нажмите Install и дождитесь завершения.

Подсказка: выбирайте WinDbg X64 на 64-битной системе и WinDbg X86 на 32-битной.

Настройка символов в WinDbg

Символы помогают отладчику расшифровывать адреса в читаемое имя функций и модулей. Настройте путь к символам Microsoft:

Добавление символов в WinDbg для анализа BSoD

Откройте WinDbg: File → Symbol File Path и вставьте (ровно так):

SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols

Нажмите OK. Рекомендуется создавать локальную папку c:\websymbols для кеша символов.

Базовый рабочий процесс в WinDbg: загрузка и первичный анализ

Откройте WinDbg (правой кнопкой — Запустить от имени администратора).
Перетащите файл дампа в окно WinDbg или используйте Ctrl + D для открытия.
Дождитесь окончания автоматического разбора; программа выведет начальную информацию.

На экране важно найти две области:

BugCheck — основной код проверки ошибок (например, 1A, 0x3B и т.д.)
Probably caused by — имя подсказки о модуле/драйвере, который, вероятно, вызвал аварийную ситуацию

Начальный анализ WinDbg

Команда для подробного анализа

Введите команду:

!analyze -v

Эта команда выдаст расширенный анализ, в котором обратите внимание на:

BugCheck Analysis — сводка по ошибке
Arguments — параметры BugCheck (Arg1, Arg2 и т.д.)
Stack trace — стек вызовов
Module list — список загруженных модулей на момент аварии

Пример: BugCheck 1A с пометкой Memory_Management и аргументами указывает на проблемы с управлением памятью или повреждённой таблицей страниц (PTE — Page Table Entry).

Что делать с выводом WinDbg

Если видно конкретный модуль (.sys или .dll) как «Probably caused by», проверьте, к какому устройству он относится.
Проверьте, есть ли доступные обновления для драйвера этого устройства.
Если виноват системный файл ntoskrnl.exe, ищите признаки аппаратных проблем (RAM, диск), либо конфликт драйверов.
Используйте команды .symfix и .reload для корректной загрузки символов, если их нет.

Команды-напоминания:

.symfix
.reload
lmvm 
kv
!thread
!process 0 0

Каждая команда даёт разный ракурс: lmvm — информацию о модуле; kv — свёрнутая распечатка стека; !thread/!process — состояние потоков и процессов.

Частые коды BugCheck и что они обычно означают

Ниже — таблица распространённых кодов с кратким объяснением. Это не исчерпывающий список, но стартовый справочник.

0x1A (MEMORY_MANAGEMENT) — ошибки управления памятью, повреждение PTE
0x3B (SYSTEM_SERVICE_EXCEPTION) — сбой в системном сервисе, часто из-за драйверов или видеодрайверов
0x7E (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) — исключение потока, обычно из-за драйвера
0x50 (PAGE_FAULT_IN_NONPAGED_AREA) — обращение к несуществующей памяти; часто RAM или драйвер
0xD1 (DRIVER_IRQL_NOT_LESS_OR_EQUAL) — неправильный доступ к памяти из режима драйвера
0xEA (THREAD_STUCK_IN_DEVICE_DRIVER) — драйвер графического устройства завис в цикле

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

Как анализировать stack trace и модули

Стек вызовов показывает последовательность функций, приведшую к крашу. Если в верхушке стека есть пользовательский драйвер, фокусируйтесь на нём.

Проверяйте:

Версию и дату драйвера
Совпадает ли модуль с тем, что отображают логи BlueScreenView
Есть ли известные баги для этой версии драйвера в интернете

Поиск в сочетании: “BugCheck 1A Arg1 <адрес> <имя модуля>” часто даёт похожие кейсы и возможные решения.

Работа с BlueScreenView — быстрая альтернатива

Если WinDbg кажется слишком сложным, используйте BlueScreenView. Он читает те же минидампы, но выводит информацию в упрощённом виде.

Скачайте и установите BlueScreenView с сайта NirSoft.
Откройте программу — она автоматически загрузит все минидампы из C:\Windows\Minidump.
Сортируйте по Crash Time и смотрите Bug Check String, Code и Parameters.

BlueScreenView: упрощённый анализ дампов

BlueScreenView удобен для быстрых проверок и формирования поискового запроса для Интернета. Он показывает примерные виновники (имя .sys) и параметры, которые нужны для поиска решений.

Сравнение WinDbg и BlueScreenView

Простота: BlueScreenView выигрывает — минимум настроек.
Глубина: WinDbg даёт детальный анализ и доступ к низкоуровневым командам.
Скорость: BlueScreenView быстрее для первичного осмотра.
Требования: WinDbg требует настройки символов и базовых знаний.

Вывод: используйте BlueScreenView для быстрой проверки. Если нужно точное понимание и подтверждение, переходите в WinDbg.

Шаблон отчёта о BSoD (для техподдержки и администраторов)

Используйте этот шаблон, чтобы собрать репорт, который упростит расследование.

Дата и время краша:
Код BugCheck (и строка):
Содержимое строки “Probably caused by”:
Путь к дампу: (minidump / memory.dmp)
Описание действий перед крашем (что выполнялось):
Недавние изменения в системе (драйверы, обновления, новый софт):
Результаты тестов памяти (memtest) и диска (chkdsk / SMART):
Приложенные логи и снимки экрана: (прилагаются)
Первичные шаги предпринятые для восстановления: (что проверено/откатано)

Шаблон ускоряет передачу инцидента между уровнями поддержки.

Оперативный SOP — что делать администратору при поступлении инцидента BSoD

Попросите пользователя не перезагружать устройство до сохранения дампа (если возможно).
Соберите минидамп (или полный дамп) и скриншоты ошибки.
Выполните проверку оперативной памяти (memtest86+) на 1–2 прохода.
Проверьте диск на ошибки и SMART-статусы.
Используйте BlueScreenView для быстрой идентификации подозреваемого модуля.
Если модуль — сторонний драйвер, запросите версию у поставщика или откат до предыдущей версии.
Если подозрение на аппаратные неисправности — замените модуль / выполните тесты на другом совместимом оборудовании.
Ведите запись всех изменений и результатов тестов.
При невозможности восстановления — инициируйте откат системы или замену узла.

Критерии приёмки: проблема решена, если BSoD не повторяется в течение согласованного окна тестирования (например, 48–72 часа) при применимых сценариях использования.

Чек-листы по ролям

Администратор / инженер:

Собраны дампы и логи
Произведён подробный анализ в WinDbg (или приложен анализ с BlueScreenView)
Проверена память и диск
Откат/обновление драйверов выполнен/запланирован
Оповещён поставщик драйвера, если необходимо

Пользователь:

Перезапустил систему и сделал скриншот кода ошибки
Отправил отчёт в техподдержку с указанием действий перед крашем
Не ставит непроверенные драйверы и не включает разгон до завершения диагностики

Когда анализ не помогает: варианты и дальнейшие шаги

Инструменты иногда дают неоднозначные результаты. Что делать, если:

“Probably caused by” указывает на ntoskrnl.exe: проверьте оборудование и взаимозависимости драйверов.
Несоответствие между WinDbg и BlueScreenView: перепроверьте символы и версию дампа.
Ошибка повторяется на разных устройствах: ищите общий софт или обновление Windows.
Нет дампов: включите запись дампов и попытайтесь восстановить сценарий, при котором появляется ошибка.

Если стандартные шаги не помогают — используйте методику исключения: заменяйте по одному элементу (RAM модули, диск, видеокарта) и проверяйте стабильность.

Мини-методология расследования BSoD (5 шагов)

Сбор данных: дамп, скриншот, описание.
Первичная фильтрация: BlueScreenView — найти подозреваемый модуль.
Подтверждение: WinDbg + символы, посмотреть стек и аргументы BugCheck.
Исправление: обновление/откат драйвера или замена аппаратного компонента.
Верификация: прогон профилированных сценариев и окно наблюдения.

Набор тестов для проверки исправления (acceptance)

«Smoke test» — загрузка ОС и выполнение типичных задач 1 час.
Нагрузочный тест — запуск стрессовых утилит (CPU, IO, GPU) в течение 2–4 часов.
Тест стабильности памяти — MemTest86+ один полный проход.
Репликация сценария пользователя, при котором возникал BSoD.

Критерий приёмки: отсутствие BSoD в течении согласованного окна тестирования при воспроизведении сценариев.

План отката / runbook на случай ухудшения ситуации

Если исправление привело к нестабильности — верните систему к предыдущему состоянию (точка восстановления, образ системы, откат драйвера).
В случае критичной производственной системы — вывести узел из обслуживания и переключить нагрузку на резерв.
Сообщить заинтересованным сторонам и заказать аппаратные детали/помощь поставщика.

Примеры ошибок и когда инструменты не помогут

Аппаратные дефекты intermittent (прерывистые) могут не проявляться во время тестирования.
Коррупция данных на диске иногда приводит к ошибки, но дамп содержит неполные данные.
Специфичные баги прошивок или материнской платы — их не всегда видно в дампе; нужен аппаратный тест.

В таких случаях ключ — воспроизведение ошибки и последовательная замена компонентов.

Безопасность и конфиденциальность при пересылке дампов

Дамп памяти может содержать чувствительные данные (пароли, ключи, личную информацию). Перед передачей третьим лицам:

Просмотрите содержание, если это возможно, и удалите очевидно чувствительные подробности.
Используйте защищённые каналы передачи и шифрование архива.
Соблюдайте внутренние правила конфиденциальности и политики GDPR, если применимо.

Короткая шпаргалка (cheat sheet)

Быстро: BlueScreenView → идентификация модуля → поиск в интернете
Глубоко: WinDbg + !analyze -v → lmvm → проверить версии драйверов
Проверки оборудования: memtest86+, chkdsk, SMART
Символы: SRVc:\websymbolshttp://msdl.microsoft.com/download/symbols

Решение для частых сценариев

Если виноват драйвер видео: обновите/откатите драйвер, проверьте тепловой режим и питание GPU
Если виноват драйвер сетевой карты: отключите ускорение, обновите драйвер, проверьте совместимость антивируса
Если виноват RAM: запустите memtest и замените модуль при ошибках

Примеры поисковых запросов, которые работают

“BugCheck 1A Memory_Management Arg1 <адрес> ntoskrnl”
“DRIVER_IRQL_NOT_LESS_OR_EQUAL .sys “
“PAGE_FAULT_IN_NONPAGED_AREA minidump”

FAQ

Как включить минидампы, если они не создаются?

Откройте “Панель управления → Система → Дополнительные параметры системы → Параметры загрузки и восстановления” и в разделе “Запись отладочной информации” выберите “Малый дамп (256 КБ)”. Укажите путь %SystemRoot%\Minidump.

Могу ли я отправить дамп стороннему специалисту?

Да, но убедитесь, что вы соблюдаете правила конфиденциальности. Шифруйте файл и прикладывайте краткое описание ситуации.

Как быстро проверить память и диск?

Для памяти — MemTest86+ (загрузочная флешка). Для диска — chkdsk /f и проверка SMART с помощью утилит типа CrystalDiskInfo.

Короткое резюме

Соберите дампы и базовую информацию.
Начните с BlueScreenView для быстрого анализа.
Используйте WinDbg с символами для глубокого анализа и подтверждения виновника.
Применяйте последовательные тесты памяти и диска.
Документируйте все шаги и используйте шаблоны отчётов при эскалации.

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

Исправление синего экрана смерти (BSoD) в Windows: пошаговое руководство