Код CRITICAL_PROCESS_DIED - это не произвольная фраза на синем экране, а официальное имя bug check. В справке Microsoft у него значение 0x000000EF. Система ставит этот код, когда завершился процесс, помеченный как критический: без него нельзя ручаться за целостность Windows. Рядом на кадре иногда виден файл. Это место, где сбой заметили, не всегда «виновник, который надо скачать заново».

Почему это происходит

Умер служебный процесс. Встроенные критические службы Windows - csrss.exe, wininit.exe, logonui.exe, smss.exe, services.exe, conhost.exe, winlogon.exe. Встречается и lsass.exe. Разработчик теоретически может пометить свою службу так, чтобы при её падении компьютер уходил в перезагрузку, но в быту почти всегда падает системный процесс, не игра.

Параметры кода, если вы их видите. Первый параметр - объект процесса. Второй: 0 - завершился процесс, 1 - завершился поток. Третий и четвёртый зарезервированы. Дома эти цифры сами по себе мало что чинят. Они нужны тому, кто открывает дамп. Не ищите в интернете «лечение параметра 1» - такой инструкции нет.

Повреждение состояния процесса. Microsoft прямо пишет: проверка срабатывает, когда состояние критического процесса повреждено. Отсюда типичные бытовые причины - битые системные файлы, драйвер, который испортил память процесса, диск, который отдал мусор вместо библиотеки.

Путают с другими кодами. 0xc0000005 - это STATUS_ACCESS_VIOLATION у приложения, стол обычно живой. 0x7B - INACCESSIBLE_BOOT_DEVICE, система не видит загрузочный диск на старте. 0x3B - SYSTEM_SERVICE_EXCEPTION, исключение в сервисе или драйвере. 0xEF не заменяет эти значения и не означает «любой синий экран».

Как проверить пошагово

  1. Сверьте написание. На экране должно быть CRITICAL_PROCESS_DIED латиницей целиком. Если написано иначе или только «process died» без CRITICAL - не додумывайте. Сфотографируйте кадр.
  2. Найдите 0xEF в журнале. «Просмотр событий» → «Система» → событие BugCheck. В данных будет 0x000000ef. Это подтверждение, что вы смотрите тот самый код, а не соседний.
  3. Не скачивайте файл с именем кода. Нет драйвера critical_process_died.sys и нет официального патча «для 0xEF». Лечат причину: откат, sfc, диск, память.
  4. Соберите минидампы. Папка C:\Windows\Minidump. Дома открывать необязательно. Случайный «анализатор» из поиска часто показывает только ntoskrnl.exe и предлагает купить программу. Ядро почти всегда крайнее, это не диагноз.
  5. Идите по обычной цепочке 0xEF. Безопасный режим, откат обновления и драйвера, sfc и DISM, chkdsk, mdsched.exe. Код говорит «умер критический процесс», но не говорит «замените видеокарту».
  6. Не правьте реестр, чтобы «сделать процесс некритическим». Отключить критичность системных служб через чужой .reg - способ получить непредсказуемую систему, которую потом не починить без установки заново.

Если код появился один раз после сбоя питания и больше не повторялся, достаточно записать его и проверить диск при случае. Повторяющийся 0xEF уже не «код ради кода»: нужна причина. Когда sfc тих, а SMART плохой, код врёт только в том смысле, что виноват накопитель, не «процесс Windows как сущность».

В дампе WinDbg после !analyze -v вы увидите то же имя CRITICAL_PROCESS_DIED и параметр, умер процесс или поток. Дома ставить отладчик незачем: достаточно сохранить Minidump. Случайные сайты с «расшифровкой кода» часто подсовывают общий текст про вирусы и кнопку скачать. Это не чтение дампа. Если процесс в дампе - сторонний антивирус, снимайте его. Если csrss.exe и рядом диск с ошибками SMART - меняйте накопитель, не «переустанавливайте csrss». Код 0xEF сам по себе не выбирает деталь для покупки.

Часто задаваемые вопросы

0xEF и CRITICAL_PROCESS_DIED - разные ошибки? Нет. Это имя и числовое значение одного bug check.

Нужно ли запоминать параметры? Не обязательно. Фото кадра и дамп полезнее, чем четыре числа из памяти.

Это вирус? Иногда вредонос портит системные файлы, и процесс падает. Сам код не означает заражение. Сначала откат и диск, потом уже проверка защитником.

Почему в поиске пишут «код 11» рядом? Имеют в виду Windows 11. Отдельного кода 11 у этой ошибки нет.

Смотрите также