Словом «проблема» в запросе люди обычно имеют в виду не разовый синий кадр, а серию. CRITICAL_PROCESS_DIED - настоящий стоп-код 0x000000EF: умер критический процесс. Один раз после грозы это неприятность. Три раза за вечер - уже задача, которую надо сузить, а не «ещё раз перезагрузить».

Это не ошибка установки Windows и не 0x80070643 в журнале Центра. Пока на экране 0xEF, рабочего стола нет. После перезапуска система может встать и тут же упасть снова на том же месте. Вот это уже проблема, а не кадр.

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

Один и тот же драйвер на входе. Антивирус, VPN, свежее видео. Падение повторяется в первой минуте после пароля. Безопасный режим это хорошо отделяет: там тихо, в обычном - снова 0xEF.

Диск в процессе умирания. SMART ещё не красный или вы его не смотрели. Критические процессы читают мусор через раз. «Проблема» выглядит как случайность, на деле - накопитель.

Недолеченные файлы. sfc не докрутили, WinSxS почистили «ускорителем», обновление оборвали. Каждый запуск снова наступает на ту же дыру.

Память. Реже. Повторы без общего действия, в разное время суток.

Путают с другими повторяющимися экранами. DPC_WATCHDOG_VIOLATION при копировании, MEMORY_MANAGEMENT в играх - другие имена. Если каждый раз на кадре не CRITICAL_PROCESS_DIED, у вас не эта проблема, даже если «синий экран опять».

Не существует багчека PROBLEM_CRITICAL_PROCESS_DIED. Запрос бытовой. Код тот же 0xEF.

Что делать самому

  1. Соберите серию, не один кадр. Когда падает: вход, копирование, простой, после сна. Имя каждый раз CRITICAL_PROCESS_DIED? Файл на экране один и тот же? Без этого вы лечите вслепую.

  2. Безопасный режим как развилка. Тихо в безопасном - снимите автозагрузку и свежие драйверы. Падает и там - диск и файлы, не оверлей Discord.

  3. Диск раньше переустановки. CrystalDiskInfo, копия данных, если SMART уже жёлтый. Ставить Windows поверх сыплющегося SSD - способ получить ту же проблему через день и решить, что «система кривая».

  4. DISM и sfc /scannow до конца. Не подменяйте csrss.exe и .sys с форума. Повтор 0xEF после чужого файла ядра - ожидаемый исход, плюс может приехать 0x139.

  5. Откат KB, если серия началась в день обновления. Журнал Центра, удаление конкретного пакета. Не отключайте обновления навсегда: заморозите хвост.

  6. Не правьте реестр критических процессов. Отключение флага critical прячет синий экран и оставляет систему без предохранителя. Так делать нельзя. «Проблема» никуда не денется, только станет тише и опаснее для файлов.

Если серия идёт уже неделю, диск зелёный, откаты сделаны и 0xEF всё равно на входе - честнее чистая установка, чем ещё один «ремонт одним кликом». Если данные не нужны, это часто быстрее. Если нужны - сначала копия, потом чистая система на том же живом диске.

Имеет смысл завести короткий список: дата, действие перед кадром, безопасный режим да/нет, SMART. Через три записи обычно видно паттерн. Без списка вы каждую перезагрузку начинаете с нуля и решаете, что «проблема необъяснимая». Необъяснимых 0xEF мало: либо одно действие, либо железо.

Не лечите повторяющийся CRITICAL_PROCESS_DIED советами от DPC_WATCHDOG_VIOLATION только потому, что оба синие. Соседние статьи можно читать для диска, но реестр сторожа и RST не закрывают умерший csrss.exe, если виноваты файлы. Имя на кадре каждый раз переписывайте заново: иногда серия внезапно меняет багчек, и это уже другая история.

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

Сколько раз 0xEF - уже проблема? Повтор за день или стабильно после одного действия. Один раз после грозы - понаблюдать.

Поможет ли переустановка? Если диск живой, а виноваты файлы и хвосты - да. Если SSD сыпется - нет.

Windows 11 болеет этим чаще? Код тот же. На 11 его просто чаще ищут.

Нужно ли менять все драйверы сразу? Нет. С последнего изменения и с файла на кадре.

Можно ли работать, если падает раз в неделю? Плохая идея. Каждый 0xEF - риск для несохранённых данных и для диска, если он уже сыпется.

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