Справочник системных ошибок и решений

Windows Server, Active Directory, 1С:Предприятие, СУБД, Linux, Cisco, MikroTik, Asterisk.

⚠️ Важная информация Все материалы, инструкции, команды и скрипты на сайте предоставлены исключительно в ознакомительных целях. Их применение может повлиять на работу операционной системы, программного обеспечения, баз данных, сетевого оборудования и других компонентов инфраструктуры. Перед выполнением действий создайте резервную копию и по возможности протестируйте изменения в безопасной среде. Пользователь самостоятельно оценивает риски и несет ответственность за результат. При отсутствии необходимых знаний обратитесь к квалифицированному ИТ-специалисту.

ntoskrnl.exe Windows Server

BSOD ntoskrnl.exe: Анализ дампа и поиск реальной причины синего экрана

Обновлено: 08.09.2026 · Официальная документация ↗

Архитектура ядра и почему винят ntoskrnl.exe

ntoskrnl.exe (Windows NT Operating System Kernel) — это ядро и исполнительная подсистема операционной системы Windows. Когда утилиты вроде BlueScreenView или WhoCrashed указывают на этот файл как на причину BSOD (Синего экрана смерти), это ошибка парсинга. Само ядро ломается крайне редко. Суть в том, что сторонний драйвер (.sys) совершает недопустимую операцию (например, обращается к невыделенной памяти), ядро перехватывает это исключение (Bug Check) и останавливает систему, чтобы предотвратить коррупцию данных. В стеке вызовов ядро всегда оказывается последним, поэтому примитивные утилиты обвиняют его. Бизнес-риски: постоянные ребуты серверов виртуализации, потеря несохраненных транзакций в СУБД.

Типовые коды остановок (Stop Codes), связанные с ядром

BugCheck CodeСимвольное имяОсновная причина
0x0000000AIRQL_NOT_LESS_OR_EQUALДрайвер обратился к выгружаемой памяти на слишком высоком IRQL (прерывании).
0x0000001AMEMORY_MANAGEMENTФизический дефект планки ОЗУ (RAM) или повреждение таблиц страниц памяти.
0x0000003BSYSTEM_SERVICE_EXCEPTIONСбой при выполнении системного вызова, часто из-за драйверов видеокарты (dxgkrnl).

Алгоритм глубокого анализа дампа (WinDbg)

Сценарий 1: Анализ стека вызовов в WinDbg

Единственный верный способ найти виновника — использовать официальный отладчик от Microsoft (WinDbg Preview из Microsoft Store или SDK).

  1. Откройте файл дампа (обычно C:\Windows\Minidump\*.dmp или C:\Windows\MEMORY.DMP) в WinDbg.
  2. Дождитесь загрузки символов (Symbols).
  3. В командной строке отладчика введите команду !analyze -v и нажмите Enter.
  4. Прокрутите вниз до секции STACK_TEXT. Ищите в списке вызовов (сверху вниз) первый файл, не относящийся к Microsoft (например, nvlddmkm.sys, e1d68x64.sys, ks.sys). Это и есть настоящий виновник.

Сценарий 2: Ловля "плавающих" багов через Driver Verifier

Если анализ дампа показывает только функции ядра (nt!KeBugCheckEx), значит драйвер повредил память тайно, и ядро упало позже. Включаем средство проверки драйверов.

 Запуск Verifier из командной строки
verifier.exe
 1. Создать нестандартные параметры (для разработчиков)
 2. Выбрать всё, КРОМЕ "Имитация нехватки ресурсов"
 3. Выбрать "Автоматически выбирать неподписанные драйверы" или выбрать конкретные драйверы вручную
 4. Перезагрузка. При следующем BSOD система выдаст код DRIVER_VERIFIER_DETECTED_VIOLATION и точное имя драйвера.

Типовые ошибки администраторов

  • Слепая вера BlueScreenView: Удаление или попытка заменить системный файл ntoskrnl.exe из-за отчета BlueScreenView приведет к полной неработоспособности ОС.
  • Забытый Driver Verifier: Включенный Verifier снижает производительность системы на 20-30%. После нахождения сбойного драйвера ОБЯЗАТЕЛЬНО отключите его командой verifier /reset.
Windows Server уходит в ребут без явных причин?
Плавающие BSOD'ы на серверах могут быть вызваны деградацией RAID-контроллеров или багами в драйверах антивируса. Аналитики ITSTM расшифруют полные дампы ядра (Kernel Memory Dumps) и точно укажут на аппаратный или программный источник проблемы.
💡 Практика специалистов: Практика ITSTM: При анализе дампов, связанных с ошибками MEMORY_MANAGEMENT, мы не всегда виним планки ОЗУ. Очень часто к коррупции пула памяти (Pool Corruption) приводят VPN-клиенты (CheckPoint, Cisco AnyConnect) и их драйверы NDIS-фильтров. Обновление их версий спасает от 80% подобных BSOD.

Частые вопросы (FAQ)

Где найти файл дампа памяти, если папки Minidump нет?

По умолчанию Windows может создавать один полный дамп ядра по пути C:\Windows\MEMORY.DMP. Если и его нет, проверьте настройки: 'Дополнительные параметры системы' -> 'Загрузка и восстановление' -> убедитесь, что запись отладочной информации включена и настроен файл подкачки (pagefile.sys).

WinDbg пишет 'Your debugger is not using the correct symbols'. Что делать?

Настройте путь к серверам символов Microsoft. В WinDbg введите команду: .sympath srv*c:\symbols*http://msdl.microsoft.com/download/symbols , а затем выполните .reload .

Если виновник ntkrnlmp.exe — это то же самое, что ntoskrnl.exe?

Да, ntkrnlmp.exe — это многопроцессорная (Multi-Processor) версия ядра ОС Windows. Принципы диагностики абсолютно те же: нужно искать сторонний драйвер в стеке (Call Stack).

Что делать, если система ушла в цикличный BSOD после включения Verifier?

Загрузитесь в безопасный режим (Safe Mode) или в среду восстановления (WinRE), откройте командную строку и введите 'verifier /reset' для сброса настроек проверки драйверов.

Полезные материалы
Рекомендуем