| Предыдущий | Следующий |
| UNMOUNTABLE_BOOT_VOLUME | STORAGE_MINIPORT_ERROR |
CRITICAL_PROCESS_DIED
Bug check CRITICAL_PROCESS_DIED имеет значение 0x000000EF. Это означает, что критически важный системный процесс завершился. Критическим считается процесс, завершение которого вынуждает систему выполнить проверку ошибки. Это может произойти, если состояние процесса повреждено. Поскольку такие процессы критически важны для работы Windows, при их повреждении система выполняет проверку ошибки: целостность операционной системы оказывается под сомнением.
К встроенным критически важным системным службам Windows относятся csrss.exe, wininit.exe, logonui.exe, smss.exe, services.exe, conhost.exe и winlogon.exe.
Разработчик также может создать службу и задать для неё действие восстановления «Перезагрузить компьютер»; дополнительные сведения см. в статье о настройке действий восстановления при сбое службы.
Параметры CRITICAL_PROCESS_DIED
| Параметр | Описание |
|---|---|
1 |
Объект процесса |
2 |
Если значение равно 0, завершился процесс. Если значение равно 1, завершился поток. |
3 |
Зарезервировано |
4 |
Зарезервировано |
Устранение неполадок
Для определения причины этой проблемы обычно требуется отладчик, позволяющий собрать дополнительные сведения. Следует изучить несколько файлов дампа и проверить, повторяются ли у stop code общие признаки, например выполнявшийся в момент остановки код.
Подробнее см. Анализ аварийных дампов с помощью отладчиков Windows при расследовании CRITICAL_PROCESS_DIED (WinDbg), использование расширения !analyze и !analyze.
Во многих случаях перед проверкой системы также создаётся дамп пользовательского режима. Как правило, при наличии пользовательского дампа сначала следует исследовать его, чтобы найти первопричину. Это связано с ограничениями отладки кода пользовательского режима по дампу ядра, включая выгруженные или отсутствующие данные. Дополнительные сведения см. в разделе «Файлы дампа пользовательского режима».
Проверьте журнал событий на наличие ошибок, предшествовавших появлению этого stop code. Такие ошибки могут указать конкретные службы или другой код, который следует исследовать.
Получив сведения о рассматриваемом коде, установите breakpoint перед его выполнением и пошагово пройдите вперёд, отслеживая значения критических переменных, управляющих потоком выполнения. Внимательно проверьте этот участок кода на ошибочные предположения и другие дефекты.
По второму параметру проверки определите, была ли она вызвана завершением процесса или потока.
Если завершился процесс, командой !process выведите сведения о нём до и после точки сбоя и найдите аномальное поведение. Утилита Process Explorer позволяет получить общие сведения о выполняющихся процессах и связях между родительскими и дочерними процессами.
Если завершился поток, командой !thread выведите сведения о нём. Сведения о потоках режима ядра см. в разделе «Изменение контекстов».
Общие сведения о потоках и процессах, а также о защищённом критически важном коде Windows, включая wininit и csrss, приведены в книге «Внутреннее устройство Windows» Павла Йосифовича, Марка Е. Руссиновича, Дэвида А. Соломона и Алекса Ионеску.
Общие рекомендации по устранению
Если вы не можете использовать отладчик, могут помочь следующие общие рекомендации.
exe) следующей командой.
REM CRITICAL_PROCESS_DIED diagnostic command. SFC /scannowПодробнее см. Использование System File Checker для восстановления отсутствующих или повреждённых системных файлов.
См. также
Анализ дампа режима ядра с помощью WinDbg
Нужно найти другой код? Найти другой код состояния или ошибки.