Event 6008 Windows: Предыдущее завершение работы было неожиданным
Архитектура подсистемы питания и логика Event 6008
Событие Event ID 6008 (Предыдущее завершение работы системы было неожиданным / The previous system shutdown was unexpected) от источника EventLog генерируется при загрузке операционной системы. Когда Windows корректно выключается, она записывает специальный маркер (Dirty Shutdown Flag = 0) в реестр. При следующей загрузке ядро проверяет этот маркер. Если маркера нет (например, выдернули шнур питания, сервер намертво завис или гипервизор убил процесс ВМ), генерируется событие 6008. Само по себе событие 6008 не содержит причины сбоя — это лишь констатация факта аппаратного сброса. Бизнес-риски: потеря транзакций в базах данных, коррупция файловой системы (RAW-диски), аппаратный выход из строя.
Типология неожиданных перезагрузок (Hard Resets)
| Тип сбоя | Сопутствующие события в Журнале (System) | Вектор диагностики |
|---|---|---|
| Потеря питания / БП | Событий перед 6008 нет (журнал просто обрывается). | Аппаратная часть: ИБП (UPS), блоки питания (PSU), логи iLO/iDRAC. |
| Аппаратный Lockup (Зависание) | Ошибки WHEA-Logger или отсутствие активности часами. | Процессор (Overheating), память, сбой материнской платы (NMI). |
| BSOD без записи дампа | Event 1001 (BugCheck) может отсутствовать, если диск отвалился. | Отключение автоматической перезагрузки при отказе ОС. |
Методика расследования Hard Resets (Event 6008)
Сценарий 1: Корреляция событий (Что было ДО сбоя)
Поскольку 6008 пишется ПОСЛЕ перезагрузки, искать причину нужно по метке времени, указанной в самом сообщении (например: завершение работы в 14:05:00).
- Откройте Event Viewer -> Система. Отфильтруйте по времени: за 10-15 минут ДО времени, указанного в событии 6008.
- Ищите системные предупреждения: перегрев (Thermal-Polling), ошибки диска (disk, ntfs, storport), ошибки сетевых интерфейсов (e1dexpress).
- Проверьте журнал Приложение (Application): возможно, ресурсоемкий процесс (СУБД) исчерпал всю память (Resource-Exhaustion-Detector).
Сценарий 2: Аппаратная диагностика (IPMI/BMC)
Если сервер упал "молча" (логов в ОС нет), ОС не виновата. Виновато железо.
- Зайдите в консоль управления сервером (HP iLO, Dell iDRAC, Cisco CIMC).
- Откройте System Event Log (SEL) или Hardware Logs.
- Ищите записи типа:
Power Supply Failure,CPU Machine Check Exception (MCE),Uncorrectable ECC Memory Error.
Типовые ошибки администраторов
- Поиск программной причины при проблемах с UPS: Администраторы часами анализируют логи Windows, в то время как сервер просто ребутается из-за севшей батареи в ИБП, который при малейшем скачке напряжения роняет нагрузку.
- Отключенный файл подкачки (Pagefile): Если ОС падает в Синий Экран (BSOD), но файл подкачки на диске C: отключен, ядро не сможет записать дамп памяти (Crash Dump), и после ребута вы увидите только 'пустое' событие 6008 без BugCheck (1001).
Нестабильное железо — бомба замедленного действия. Эксперты ITSTM проведут глубокий аудит аппаратной платформы, снимут метрики IPMI и настроят корректные политики Graceful Shutdown через агенты ИБП (PowerChute).
Частые вопросы (FAQ)
Почему событие 6008 появляется на виртуальных машинах (Hyper-V/VMware)?
Гипервизор либо жестко 'убил' процесс ВМ (Power Off), либо хост виртуализации сам внезапно перезагрузился (Host Crash). Также причиной может быть зависание ВМ внутри (Guest OS Hang) и последующий сброс через гипервизор.
Что такое NMI (Non-Maskable Interrupt)?
Это немаскируемое аппаратное прерывание. Если сервер намертво зависает, администратор может послать NMI через iLO/iDRAC. Windows перехватит его и принудительно выпадет в BSOD, записав дамп памяти для анализа причин зависания.
Как предотвратить автоматическую перезагрузку при BSOD?
Свойства системы -> Дополнительно -> Загрузка и восстановление -> Снимите галочку 'Выполнить автоматическую перезагрузку' (Automatically restart). При сбое сервер останется висеть на синем экране, позволяя прочитать код ошибки (Stop Code).
Связано ли событие 41 (Kernel-Power) с 6008?
Да, они почти всегда идут парой. Событие 41 (Система перезагрузилась, завершив работу с ошибками) генерируется компонентом Kernel-Power сразу после загрузки ОС и подтверждает факт, описанный в событии 6008.