Проблема
Синий экран смерти (Blue Screen of Death) та самая неприятность, которая вынуждает администратора отрываться от текущих задач и ломать голову над внезапной перезагрузкой сервера или рабочей станции. Экран с «печальным смайликом» и сообщением Your PC ran into a problem содержит критически важную информацию: шестнадцатеричный STOP-код, параметры ошибки и, при удачной настройке, имя проблемного модуля. Однако большинство пользователей и начинающих сисадминов эту информацию игнорируют, просто перезагружая систему в надежде, что «само пройдёт». Такой подход приводит к накоплению нерешённых проблем и повторяющимся сбоям. BSOD Windows это не приговор, а диагностический инструмент, который при правильной расшифровке позволяет быстро локализовать неисправное оборудование, сбойный драйвер или повреждённый системный файл. В этой статье мы разберём алгоритм анализа дампа памяти и научимся интерпретировать самые частые STOP-коды. Ранее я уже писал о диагностике «синего экрана» (BSOD), будет также полезно.
Решение
Для системного подхода к диагностике BSOD необходимо настроить автоматическое сохранение аварийных дампов памяти, обеспечить доступ к инструменту отладки (WinDbg) и освоить базовые приёмы чтения вывода анализатора. Такой подход регламентирован официальной документацией Microsoft Analyze a Kernel-Mode Dump File with WinDbg и руководством по отладке Blue Screen Data. Алгоритм работает на всех поддерживаемых версиях Windows 10 и 11, а также на Windows Server 2016/2019/2022, и не требует переустановки системы.
Пошаговая инструкция
Шаг 1. Настройка сохранения дампов памяти
По умолчанию Windows может автоматически перезагружаться после BSOD, не оставляя следа для анализа. Первым делом проверяем и настраиваем политику записи дампов.
- Нажмите
Win + R, введитеsysdm.cplи нажмите Enter. - Перейдите на вкладку Дополнительно (Advanced), в разделе Загрузка и восстановление (Startup and Recovery) нажмите Параметры (Settings).
- В блоке Отказ системы (System failure):
- Убедитесь, что стоит галочка Записать событие в системный журнал.
- Снимите галочку Автоматически выполнять перезагрузку, чтобы успеть прочитать STOP-код на экране.
- В выпадающем списке Запись отладочной информации выберите Автоматический дамп памяти (Automatic memory dump) или Активный дамп памяти (Active memory dump) для современных систем. Для серверов с большим объёмом ОЗУ можно оставить Дамп памяти ядра (Kernel memory dump).
- Убедитесь, что путь к файлу дампа
%SystemRoot%\MEMORY.DMP.
- Для углублённого анализа включите запись малого дампа (Minidump): установите переключатель в Малый дамп памяти (256 КБ) и укажите директорию, например,
%SystemRoot%\Minidump. Малые дампы занимают минимум места и пишутся при каждом сбое, тогда как полный дамп перезаписывается. - Нажмите ОК и перезагрузите компьютер, если система этого попросит.
Дополнительные сведения о типах дампов приведены в статье Varieties of Kernel-Mode Dump Files.
Шаг 2. Установка инструментов отладки (WinDbg)
WinDbg бесплатный отладчик от Microsoft, распространяемый через Windows SDK.
- Скачайте установщик Windows SDK с официального сайта Windows SDK.
- Запустите
winsdksetup.exeи на этапе выбора компонентов оставьте только Debugging Tools for Windows, снимите остальные галочки. - После установки откройте WinDbg от имени администратора (через меню «Пуск»).
Альтернативно можно использовать WinDbg Preview из Microsoft Store, но классическая версия из SDK предоставляет максимальный набор команд.
Шаг 3. Открытие и анализ дампа памяти
- Запустите WinDbg, нажмите
Ctrl + Dили выберите File → Open Crash Dump. - Укажите путь к файлу
MEMORY.DMPв папкеC:\Windowsили к последнему минидампу изC:\Windows\Minidump(рекомендуется брать самый свежий по дате). - Дождитесь загрузки дампа и автоматического выполнения начальных команд. Вы увидите строку типа:textLoading Dump File [C:\Windows\MEMORY.DMP] Kernel Bitmap Dump File: Kernel address space is available
- В нижней панели команд введите центральную команду анализа:text!analyze -vКлюч
-v(verbose) заставляет WinDbg выдать максимально подробный отчёт.
Шаг 4. Интерпретация вывода !analyze -v
Отчёт содержит несколько ключевых секций, которые следует читать сверху вниз.
4.1. Первичный STOP-код и параметры
Первая строка после BugCheck сообщает шестнадцатеричный код ошибки, например:
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
В скобках указан код 0x000000D1. Запоминаем его.
4.2. Сбойный модуль
Ищем строку Probably caused by: или MODULE_NAME:. Пример:
Probably caused by : nvlddmkm.sys ( nvlddmkm+2a1c4 )
Имя файла (nvlddmkm.sys) указывает на драйвер видеокарты NVIDIA. Именно этот драйвер спровоцировал BSOD.
4.3. Стек вызова
Секция STACK_TEXT показывает последовательность вызовов функций ядра и драйверов, предшествовавших сбою. Адреса без символов обозначены знаками вопроса, но после настройки символов (см. шаг 5) имена функций станут читаемыми. Обращайте внимание на самые верхние строки стека они указывают на код, исполнявшийся в момент краха.
4.4. FAILURE_BUCKET_ID и анализ
Строка FAILURE_BUCKET_ID содержит идентификатор ошибки в формате AV_nvlddmkm!unknown_function. Это хеш-сигнатура, которую можно загуглить для поиска аналогичных случаев. Также в секции IMAGE_NAME и FAILURE_BUCKET_ID уточняется проблемный бинарный файл.
Шаг 5. Настройка символов для точного анализа
Для получения читаемых имён функций в стеке требуется подключиться к серверу символов Microsoft.
- В WinDbg выберите File → Settings → Debugging settings или в командной строке выполните:text.sympath SRV*c:\symbols*https://msdl.microsoft.com/download/symbols .reload /f
- Первая команда задаёт путь для локального кеширования символов (
c:\symbols) и URL сервера символов. Вторая принудительно перезагружает символы для всех модулей. - После этого повторите
!analyze -v. Стек станет существенно информативнее.
Официальная справка по символам: Symbol Path for Windows Debuggers.
Шаг 6. Расшифровка распространённых STOP-кодов
Ниже перечислены коды, с которыми сталкивается 90% администраторов, их типичные причины и направления диагностики.
| STOP-код (hex) | Символическое имя | Типичная причина |
|---|---|---|
0x000000D1 | DRIVER_IRQL_NOT_LESS_OR_EQUAL | Драйвер обратился к странице памяти по недопустимому IRQL. Чаще всего драйвер сетевой карты или антивируса. |
0x0000001E | KMODE_EXCEPTION_NOT_HANDLED | Необработанное исключение в режиме ядра. Часто указывает на баг в драйвере или неисправную оперативную память. |
0x00000050 | PAGE_FAULT_IN_NONPAGED_AREA | Обращение к отсутствующей или повреждённой странице памяти. Виновник сбойный модуль ОЗУ, жёсткий диск или драйвер. |
0x0000007F | UNEXPECTED_KERNEL_MODE_TRAP | Аппаратная проблема: перегрев процессора, неисправность ОЗУ, разгон, повреждение кеша CPU. |
0x0000009F | DRIVER_POWER_STATE_FAILURE | Сбой управления питанием (обычно при выходе из сна/гибернации). Виновник драйвер чипсета, видеокарты или USB-устройства. |
0x00000133 | DPC_WATCHDOG_VIOLATION | Драйвер слишком долго выполняет отложенный вызов процедуры (DPC). Часто вызывается драйверами SSD/HDD, реже беспроводных адаптеров. |
0x0000003B | SYSTEM_SERVICE_EXCEPTION | Исключение при выполнении системной службы. Виновник драйвер графики или несовместимый антивирус. |
0x000000EF | CRITICAL_PROCESS_DIED | Критический системный процесс (csrss.exe, wininit.exe) аварийно завершён. Часто указывает на повреждение системных файлов или заражение вредоносным ПО. |
0x0000001A | MEMORY_MANAGEMENT | Серьёзная проблема с управлением памятью: неисправность модуля ОЗУ, конфликт драйверов, повреждение файла подкачки. |
0x00000109 | CRITICAL_STRUCTURE_CORRUPTION | Обнаружено повреждение критических структур данных ядра. Часто вызывается вредоносным ПО или драйвером, модифицирующим код ядра. |
При обнаружении любого из этих кодов в первую очередь проверяйте оборудование (ОЗУ через MemTest86, диск через chkdsk /f /r), обновляйте или откатывайте подозрительные драйверы и запускайте sfc /scannow для восстановления системных файлов.
Устранение распространённых проблем
| Симптом | Вероятная причина | Решение |
|---|---|---|
| WinDbg не находит файл дампа | Система не создала дамп из-за отсутствия файла подкачки или недостатка места на диске | Проверьте, что размер файла подкачки не менее объёма ОЗУ + 1 МБ на системном томе. Освободите место на диске C:. В sysdm.cpl в том же окне настройки дампа убедитесь, что выбранный диск имеет достаточно свободного пространства. |
В выводе !analyze -v нет имени драйвера | Система не смогла определить виновника; возможно, повреждён стек или дамп неполный | Включите верификатор драйверов (verifier.exe) для подозрительных модулей. Это приведёт к более детальному сбору информации при следующем BSOD. Подробнее: Driver Verifier. |
Анализ указывает на ntoskrnl.exe, но драйвер не указан | Ошибка произошла в ядре системы из-за воздействия стороннего драйвера, который не записался в стек | Используйте команду !thread и k, чтобы изучить полный стек вызовов. Сравните время сбоя с журналом событий Windows (eventvwr.msc): фильтруйте по System с источником Kernel-Power и BugCheck. Это даст дополнительный контекст. |
| Дамп создаётся, но WinDbg не может его открыть | Повреждённый файл дампа | Попробуйте открыть минидамп из папки Minidump они менее подвержены повреждению. Если все дампы битые, выполните проверку диска: chkdsk C: /f /r. |
После настройки символов часть имён функций остаётся неизвестной (unknown) | Отсутствуют символы для сторонних драйверов | Добавьте дополнительные пути к символам: .sympath+ SRV*c:\mysymbols*https://driver-symbols.example.com. Производители драйверов (NVIDIA, AMD) предоставляют символы на своих сайтах, но для публичного анализа обычно достаточно сервера Microsoft. |
Итог
BSOD Windows перестаёт быть пугающей неожиданностью, когда в руках администратора есть чёткий алгоритм: сохранить дамп, открыть в WinDbg, выполнить !analyze -v и расшифровать код. Опыт показывает, что в 70% случаев вина лежит на сторонних драйверах, и решение сводится к их обновлению или откату. Остальные проценты приходятся на аппаратные неисправности и повреждения системных файлов. Ведение собственной базы STOP-кодов и частых виновников для вашего парка машин существенно ускоряет диагностику и минимизирует простои.
