На синем экране иногда крупно имя CRITICAL_PROCESS_DIED, иногда в журнале виден 0x000000ef или 0xEF. Это не две болезни. По документации Microsoft bug check 0x000000EF так и называется: CRITICAL_PROCESS_DIED. Ноль, икс, e, f - шестнадцатеричная запись числа 239. Люди ищут «0xef critical process died», потому что одно запомнили с кадра, другое - из «Просмотра событий». Лечить нужно одну историю: умер критический процесс.

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

Ядро зафиксировало гибель критического процесса. Типичные имена: csrss.exe, wininit.exe, smss.exe, services.exe, winlogon.exe, lsass.exe. Без них Windows не продолжает. 0xEF - метка этого события, не «номер драйвера».

Откуда берётся запись 0xEF. На современном кадре Windows 10 и 11 чаще рисуют имя словами. В событии BugCheck в журнале «Система» значение будет 0x000000ef. Анализаторы дампа пишут CRITICAL_PROCESS_DIED (EF). Если вы увидели только hex без имени - это всё равно тот же код, не «неизвестная ошибка 239».

Бытовые причины те же, что у имени. Битые файлы после обновления, фильтр антивируса, умирающий диск, реже память. Hex ничего не добавляет к смыслу и ничего не вычитает. Не ищите «лечение именно 0xEF, не CRITICAL». Такого разделения нет.

Путают с 0xc0000005 и 0x7B. 0xc0000005 - нарушение доступа в приложении, обычно без синего экрана. 0x7B - INACCESSIBLE_BOOT_DEVICE, система не достучалась до загрузочного тома на старте. 0xEF случается и на загрузке, и уже со стола: процесс успел стартовать и умер. Это разные ветки диагностики.

Не существует стоп-кода 0xEFF или «0xef11». Если в запросе хвост кривой, ориентируйтесь на полный 0xEF и слово CRITICAL_PROCESS_DIED на фото.

Как действовать по шагам

  1. Сверьте hex. Допустимы записи 0xEF, 0x000000EF, 0x000000ef. Это одно. Если в журнале 0x0000003B или 0x0000007B - вы не в этой статье.
  2. Сфотографируйте кадр и сохраните дамп. Minidump в C:\Windows\Minidump. Не ставьте программу, которая обещает «исправить 0xEF за минуту». Такого исправления нет.
  3. Безопасный режим. Если при минимуме драйверов 0xEF пропадает, снимайте свежий фильтр и откатывайте драйвер. Если 0xEF остаётся - смотрите файлы, диск, память, не «ещё один чистильщик».
  4. Снимите пакет, после которого появился 0xEF. Из живой системы или из среды восстановления. Пауза обновлений на несколько дней. Не удаляйте все KB подряд.
  5. sfc /scannow, затем DISM, снова sfc. Это штатный ремонт компонентов, не замена файлов с форума. Скачанный «оригинальный» ntdll.dll под «ваш 0xEF» почти наверняка от другой сборки.
  6. Диск и память. chkdsk C: /f, mdsched.exe, для SSD - фирменная утилита. 0xEF на сыплющемся накопителе лечится заменой диска, не правкой реестра.

Если 0xEF был один раз после грозы или выключения кнопкой и больше не повторялся, достаточно записи в блокноте. Повторяющийся hex - уже поиск причины. Переустановка имеет смысл, когда компоненты не собираются, а железо тихое. На мёртвом SSD новая Windows снова напишет 0xEF.

В старых статьях пишут STOP 0x000000EF, в новых - только имя. Журнал надёжности после входа показывает красный крест в момент падения. Если рядом установка драйвера или KB, начните с отката, не с hex-калькулятора. Ноль в записи 0xEF - это цифра, не буква O. Запросы вроде «oxef» в поиске - та же путаница, отдельного кода oxef нет. Пишите 0xEF латиницей. И не склеивайте 0xEF с 0xc0000005: разные пространства номеров, разные экраны, разное лечение.

Не склеивайте 0xEF с кодами центра вроде 0x80070002. Разные экраны, разные журналы. Hex 0xEF живёт в BugCheck и на синем кадре. Центр пишет свой номер в «Параметрах», стол при этом обычно живой.

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

0xEF и CRITICAL_PROCESS_DIED нужно лечить по-разному? Нет. Это имя и число одного bug check.

Почему в журнале 0x000000ef, а в поиске пишут 0xEF? Одно и то же число, разная запись. Нули слева ничего не меняют.

Это ошибка установки Windows? Обычно нет. 0xEF - стоп-код уже установленной системы. На установке с флешки бывают другие коды.

Можно ли стереть дамп, чтобы ошибка пропала? Нет. Дамп - запись факта, не причина.

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