Синий кадр с CRITICAL_PROCESS_DIED значит, что завершился процесс, без которого Windows не имеет права жить: csrss.exe, smss.exe, wininit.exe, lsass.exe и им подобные. Числовой стоп - 0x000000EF. Система не «зависла», она сознательно остановилась. Это не PAGE_FAULT_IN_NONPAGED_AREA и не ошибка Центра. Часто приходит после обновления, «чистилки», сбоя диска или кривого драйвера, который убил процесс из ядра.

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

Повреждены системные файлы. Оборванное обновление, ручное удаление из System32, антивирус, который «вылечил» лишнее. Критический процесс стартует и сразу падает. Отличие: sfc потом находит кучу нарушений.

Диск не отдаёт исполняемый файл. HDD с бэдами, SSD в предсмертной агонии. csrss прочитался наполовину. Тогда 0xEF соседствует с KERNEL_DATA_INPAGE_ERROR или с 0xc0000098 на следующем старте.

Драйвер или фильтр убил процесс. Антивирус, «оптимизатор», старый VPN, чит. Стоп после установки конкретной программы - смотрите её, не материнскую плату.

Память врёт. Реже как единственная причина, чаще как фон. Процесс упал на искажённой странице. Имеет смысл прогнать mdsched, если диск чистый, а 0xEF случайный.

Не путайте с CRITICAL_PROCESS_DIED при установке Windows: там установщик ещё пишет файлы, причина чаще флешка и RAM. Здесь система уже стояла и работала. Не существует стопа «critical process die» без _DIED: в поиске так пишут, на экране CRITICAL_PROCESS_DIED.

На Windows 10 после нескольких 0xEF часто сами выпадают «Дополнительные параметры». На Windows 11 то же, но Fast Startup умеет прятать полный холодный старт: перед диагностикой выключайте машину через Shift + «Завершение работы». Если стоп приходит сразу на крутящемся круге, ещё до экрана входа, это ближе к диску и файлам csrss/smss, чем к «кривой игре». Если уже после рабочего стола, в момент запуска антивируса или VPN - смотрите фильтр, не SSD первым делом.

Полный дамп на весь объём памяти для домашнего разбора не нужен. Минидамп в C:\Windows\Minidump достаточный. Не отключайте запись дампов в системе «для скорости»: без файла потом останется только фото кадра.

Не подкладывайте csrss.exe и lsass.exe с форума. Это подписанные файлы конкретной сборки. Чужой бинарник даст уже отказ подписи или петлю 0xEF. Не правьте реестр Winlogon наугад.

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

  1. Сфотографируйте синий кадр. CRITICAL_PROCESS_DIED, 0x000000EF, имя файла если есть. Если стоп в цикле сразу при логотипе - флешка, кадр всё равно нужен.
  2. Зайдите в безопасный режим или WinRE. Если безопасный режим живой - снимите вчерашний антивирус, «чистилку», VPN. Если нет - «Восстановление при загрузке» и точка восстановления старше сбоя.
  3. Проверьте диск. SMART, затем chkdsk C: /f из рабочей системы или с другой буквы из WinRE. 0xEF на сыплющемся томе не лечится переустановкой драйвера мыши.
  4. Прогоните sfc /scannow и DISM RestoreHealth. Из живой Windows или офлайн, когда буква тома известна. Это штатный ремонт файлов, не «патч 0xEF».
  5. Откатите большое обновление, если стоп начался на следующее утро после пакета. В WinRE это «Удалить обновления» или точка. Не ставьте ту же сборку поверх, пока диск не проверен.
  6. Проверьте память, если диск чистый и файлы целые. Одна планка, сток, mdsched. Ошибки на тесте - меняйте модуль, не систему.

Если 0xEF повторяется на чистой Windows с того же диска - накопитель. Если на новом SSD тишина - виноват был старый диск, не «кривая десятка».

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

CRITICAL_PROCESS_DIED - это вирус? Иногда вредонос как раз и убивает lsass. Чаще - диск, обновление, антивирус. Имеет смысл проверить, но не начинать с «форматирования ради вируса».

0xEF и 0x000000EF - одно? Да. Коротко на кадре пишут 0xEF.

Поможет ли переустановка? Да, если файлы системы уже не собрать, а диск живой. Нет, если диск умирает.

Чем отличается от BAD_SYSTEM_CONFIG_INFO? 0x74 - конфигурация на старте. 0xEF - умер процесс. Разные шаги, общий WinRE.

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