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

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

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

1001 Windows Server, AD и Роли

Event ID 1001 BugCheck: Компьютер перезагружен после критической ошибки

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

Механизм BugCheck и сохранение дампов

Событие 1001 логируется источником BugCheck в журнале System сразу после того, как сервер успешно перезагрузился после Синего экрана смерти (BSOD). Сообщение гласит: «Компьютер был перезагружен после критической ошибки: [Код STOP-ошибки]. Копия памяти сохранена...». Это событие подтверждает, что ядру ОС удалось успешно сбросить содержимое оперативной памяти (Дамп) на жесткий диск для последующего анализа.

Структура параметров BugCheck (HEX)

В тексте события содержится сам код остановки (например, 0x000000d1) и 4 параметра. Эти параметры критичны для расшифровки причины, даже если файл дампа был удален.

Имя дампаРасположениеРазмер и польза
Minidump (Малый дамп)C:\Windows\Minidump\*.dmp256 КБ. Содержит только стек падения и список драйверов. Отлично подходит для 90% задач ИБ и анализа.
Kernel Dump (Дамп ядра)C:\Windows\MEMORY.DMPОт 1 до 4 ГБ. Содержит всю память ядра. Нужен для глубокой отладки зависаний (Deadlocks).
Complete Dump (Полный дамп)C:\Windows\MEMORY.DMPРавен объему ОЗУ (например, 128 ГБ). Забивает диски. Не рекомендуется для серверов.

Пошаговое дерево решений (Чтение дампов)

Сценарий 1: Расшифровка кода ошибки без дампа

Если файла дампа нет, используйте код из события 1001.

  1. Скопируйте первый HEX-код из события (например, 0x0000001A).
  2. В нашей базе знаний это >BSOD MEMORY_MANAGEMENT.
  3. Второй параметр (Parameter 1) укажет подтип ошибки (например, повреждение PTE).

Сценарий 2: Анализ через WinDbg (Рекомендуется)

Для точного поиска сбойного .sys драйвера (особенно при ошибках типа 0xD1 или 0x50):

  1. Установите WinDbg Preview (из Microsoft Store) или классический Debugging Tools for Windows.
  2. Откройте файл C:\Windows\MEMORY.DMP (потребуются права Администратора).
  3. В командной строке отладчика введите: !analyze -v
  4. Прокрутите отчет до секции MODULE_NAME и IMAGE_NAME. Там будет указан файл виновника (например, igdkmd64.sys — драйвер видеокарты).

Сценарий 3: Настройка файла подкачки (Pagefile)

Если сервер упал в BSOD (было событие 41), но события 1001 нет — значит ядро не смогло записать дамп. Причина всегда в файле подкачки.

  1. Откройте sysdm.cpl -> Дополнительно -> Загрузка и восстановление.
  2. Убедитесь, что настроена запись "Автоматического дампа памяти".
  3. Файл pagefile.sys ОБЯЗАТЕЛЬНО должен находиться на системном диске (C:) и его размер должен быть управляемым системой. Отключение pagefile запрещает сохранение дампов.

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

  • Очистка диска (Disk Cleanup): Утилиты очистки диска (включая CCleaner) по умолчанию удаляют папку Minidump и файл MEMORY.DMP. Если вы настроили авто-очистку на сервере, вы уничтожаете улики для расследования причин BSOD.
Windows Server регулярно падает, прерывая работу баз данных, а вы не умеете читать дампы?
Отладка ядра (Kernel Debugging) — это экспертный уровень ИТ. Передайте инфраструктуру на системную поддержку нам: мы найдем и вычистим конфликтующие драйверы, вернем сервер к 100% аптайму и оптимизируем железо.
💡 Практика специалистов: Если в событии 1001 указан код BugCheck 0x000000EF (CRITICAL_PROCESS_DIED), анализ дампа будет крайне сложным, так как память процесса, вызвавшего сбой, часто не выгружается в минидамп. В таких случаях мы включаем сбор Полного дампа ядра на сервере.

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

Почему 1001 появляется при зависании, хотя BSOD не было видно?

На серверах (Core или при доступе по RDP) синий экран физически не отрисовывается на мониторе. Ядро молча сбрасывает дамп и уходит в ребут. Событие 1001 — единственное подтверждение краша.

Можно ли перенести файл дампа на другой диск?

Да, в sysdm.cpl вы можете указать другой путь для файла дампа (например, D:\Dumps\MEMORY.DMP), но файл подкачки (pagefile.sys) все равно должен оставаться на диске C: для первичного перехвата данных из RAM.

Чем отличается событие 1001 от события 41 Kernel-Power?

Событие 41 говорит: 'ОС была выключена нештатно'. Оно есть всегда. А 1001 говорит: 'Это был программный краш, и я сохранил дамп'. Если 41 есть, а 1001 нет — это был аппаратный сбой (пропало питание).

Как прочитать дамп, если WinDbg пишет 'Your debugger is not using the correct symbols'?

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

Можно ли использовать утилиту BlueScreenView вместо WinDbg?

Можно для быстрой оценки, но она часто ошибается и показывает на ntoskrnl.exe (ядро), не умея глубоко анализировать стек вызовов. WinDbg — единственный профессиональный инструмент.

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