6008 Windows Server, AD и Роли

Event ID 6008 EventLog: Предыдущее завершение работы системы было неожиданным

Обновлено: 15.08.2026 · Официальная база знаний

Архитектура журналирования и аудит аварийных сбоев (Dirty Shutdown)

Событие 6008 логируется источником EventLog в журнале System сразу после того, как операционная система завершит процесс загрузки. Сообщение: "Предыдущее завершение работы системы в [Время] было неожиданным (The previous system shutdown was unexpected)". В бизнес-среде это критический индикатор аварии инфраструктуры. В отличие от штатного выключения (>1074), событие 6008 означает, что ядро ОС не успело сбросить дисковые кэши, закрыть транзакции баз данных и корректно остановить службы. Риски для бизнеса: повреждение файлов MFT (NTFS), разрушение баз Active Directory (NTDS.dit), SQL Server и почтовых хранилищ Exchange.

Физические и логические причины:

Аппаратные сбои: Полная потеря электропитания (отказ ИБП / PDU), перегрев процессора (Thermal Shutdown) или сбой оперативной памяти.
Виртуализация: Жесткое 'убийство' виртуальной машины гипервизором (Power Off / Stop вместо Guest Shutdown).
Фатальные ошибки ядра: Возникновение 'Синего экрана смерти' (BSOD), при котором система ушла в жесткую перезагрузку (сопровождается событием Kernel-Power 41).

Регламент расследования внезапных остановок серверов

Сценарий 1: Корреляция с ошибками BugCheck (Поиск BSOD)

Первым делом необходимо исключить программный сбой (падение драйверов ядра).

Откройте журнал System и найдите событие 6008.
Проверьте события в течение первых 2 минут после события 6008.
Если вы видите событие источника BugCheck (Event ID 1001) с текстом "Компьютер был перезагружен после критической ошибки..." — причиной был синий экран. Извлеките файл MEMORY.DMP и анализируйте его утилитой WinDbg.

Сценарий 2: Аппаратный аудит через контроллеры BMC (iLO / iDRAC)

Если BSOD отсутствует, проблема кроется в 'железе' или электропитании.

Зайдите в веб-интерфейс управления сервером (HPE iLO, Dell iDRAC, Lenovo XCC).
Откройте журнал аппаратных событий IML (Integrated Management Log) или SEL (System Event Log).
Ищите записи вида "Server Critical Fault", "Power Supply redundancy lost" или "Temperature threshold exceeded" в момент времени, предшествующий аварии.

Сценарий 3: Настройка политик восстановления для служб СУБД

После грязного отключения (Dirty Shutdown) базы данных должны корректно 'проиграть' логи транзакций при старте.

# Проверка целостности дисковых томов после аварийного отключения (Powershell)
Get-Volume | Where-Object HealthStatus -ne 'Healthy' | Select-Object DriveLetter, FileSystemLabel, HealthStatus

Убедитесь, что критичные службы (SQL Server) настроены на автоматический запуск (Delayed Start), чтобы дисковая подсистема успела пройти инициализацию после восстановления MPIO и iSCSI.

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

Поиск причин в самом событии 6008: Само событие 6008 не содержит причин сбоя. Оно лишь констатирует факт того, что в момент загрузки ОС обнаружила флаг незаконченного предыдущего сеанса. Причину нужно искать в логах оборудования или систем гипервизора (vCenter / SCVMM).

Серверы систематически перезагружаются, нарушая целостность баз данных?
Внезапные сбои электропитания или падения гипервизоров могут привести к невосстановимой потере корпоративной информации (Data Loss). Доверьте аудит инфраструктуры ITSTM: проведем стресс-тесты, настроим политики ИБП (UPS Shutdown) и обеспечим надежное резервное копирование (RPO/RTO).

Практический опыт инженера: Экспертная практика: В кластерах высокой доступности (Failover Cluster) периодическое появление события 6008 на узлах часто связано с механизмом 'Active Memory Dump'. Если узел теряет доступ к CSV-дискам (сетевой сбой Storage Spaces Direct), кластер инициирует BugCheck 0x9E (USER_MODE_HEALTH_MONITOR) для защиты целостности данных, что вызывает мгновенный ребут узла.

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

Почему время в описании события 6008 часто не совпадает с реальным временем сбоя?

Служба EventLog периодически (каждые несколько минут) записывает текущее время в системный реестр (Timestamp). Событие 6008 указывает именно это 'последнее сохраненное' время, которое может отличаться от фактического момента пропадания питания на 2-5 минут.

Как связано событие 6008 и Kernel-Power 41?

Это связанные события. Event 6008 логируется службой EventLog, а Kernel-Power 41 логируется подсистемой ядра (Kernel) при старте, подтверждая, что питание системы было прервано без чистого завершения работы.

Если виртуальная машина мигрировала (Live Migration), может ли появиться 6008?

При успешной 'живой' миграции — нет. Но если миграция провалилась и кластер выполнил жесткий Failover (перезапуск ВМ на другом узле с потерей состояния оперативной памяти), гостевая ОС зафиксирует грязную перезагрузку (6008).

Как принудительно отключить кеширование записи диска для защиты данных?

В диспетчере устройств (devmgmt.msc), в свойствах дискового накопителя на вкладке 'Политики' снимите галочку 'Разрешить кэширование записей для этого устройства'. Это снизит производительность, но защитит данные при потере питания.