На синем экране Windows пишет «код остановки» и имя CRITICAL_PROCESS_DIED. В журнале то же событие часто выглядит как BugCheck 0x000000EF. Это не два разных отказа и не «сначала одно, потом другое». 0xEF - шестнадцатеричный номер багчека, имя - его текстовая метка. Полная запись в документации Microsoft - 0x000000EF.

Запрос склеивает оба написания, потому что на десятке крупнее имя, а в Просмотре событий удобнее искать hex. Смысл один: завершился процесс, который система считает критическим, ядро не стало продолжать.

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

Критический процесс завершился с ошибкой. Типичные жертвы - csrss.exe, smss.exe, lsass.exe и службы, помеченные флагом критичности. Ядро не гадает, «можно ли без них»: рисует 0xEF и дамп.

Драйвер или фильтр. Антивирус, VPN, свежий пакет чипсета. Процесс падает не сам по себе, его роняет чужой код в ядре или плохой вызов. После отката 0xEF часто пропадает.

Битые системные файлы. Прерванное обновление, «очистка» папки Windows, сыплющийся диск. Тогда рядом живут жалобы sfc и повтор 0xEF на каждом втором входе.

Накопитель. Чтение страницы критического процесса с дохлого SSD даёт тот же код остановки. Новая Windows на том же диске повторит 0xEF.

Путают с 0xc0000005. Access violation у обычной программы - не код остановки. 0xEF бывает только когда уже синий кадр. Лечить «ошибку приложения» советами от 0xEF нельзя.

Не существует отдельного багчека CRITICAL_PROCESS_DIED_0XEF. Люди так ищут, чтобы склеить то, что видят на экране, с тем, что видят в журнале. Если в BugCheck другое число - 0x00000139, 0x00000050 - это уже KERNEL_SECURITY_CHECK_FAILURE или PAGE_FAULT_IN_NONPAGED_AREA.

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

  1. Сверьте имя и число. На кадре CRITICAL_PROCESS_DIED. В журнале Windows - BugCheck 0x000000ef. Совпало - вы здесь. Не совпало - не применяйте эту цепочку к чужому коду.

  2. Снимите автоперезапуск. sysdm.cpl, загрузка и восстановление. Нужно успеть прочитать имя и, если есть, файл. Это не лечение.

  3. Безопасный режим и откат последнего изменения. Драйвер, антивирус, обновление Windows из журнала. Если 0xEF начался в день пакета - начните с пакета, не с переустановки.

  4. DISM и sfc /scannow. Только штатные команды, дождитесь 100 процентов. Не подменяйте ntdll.dll, csrss.exe и любые .sys файлами с форума: подпись не сойдётся, получите уже 0x139.

  5. Диск, затем память. CrystalDiskInfo, chkdsk, при случайных падениях - mdsched.exe. Порядок такой, потому что 0xEF чаще про файлы и накопитель, чем про планку.

  6. Не ищите в реестре ключ 0xEF. Его нет. Случайные .reg «против синего экрана» ломают загрузку. Не отключайте флаг критичности процессов: спрячете кадр и оставите систему без предохранителя.

Minidump в C:\Windows\Minidump стоит сохранить, если Windows после перезапуска жива. Дома его можно не разбирать. Онлайн-сервис с рекламой «исправим 0xEF одним кликом» обычно врёт.

На Windows 11 кадр короче, QR ведёт на общую справку windows.com/stopcode, не на уникальное лекарство 0xEF. Лечение то же, что на десятке: откат, файлы, диск.

В дампе и в старых статьях встречается запись Bug Check 0xEF с четырьмя параметрами. Первые обычно указывают на процесс, который умер. Дома это редко помогает без отладчика, и не нужно искать «значение параметра 1 как артикул». Достаточно знать: имя CRITICAL_PROCESS_DIED и число 0xEF совпали. Дальше обычная цепочка, не «патч под параметр».

Если в журнале 0xEF чередуется с другим багчеком за те же сутки, запишите оба. Общий корень часто диск. Не применяйте к 0xEF лечение от 0x7B и наоборот: загрузчик и критический процесс - разные этажи. Среда восстановления чинит старт, DISM чинит файлы уже загруженной системы.

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

0xEF и 0x000000EF - одно? Да. Короткая и полная запись.

Почему на экране нет числа, а в журнале нет имени? Так устроен вывод. Сверяют оба источника.

Это код обновления Windows? Нет. Обновление пишет HRESULT вроде 0x80070643 при живом столе. 0xEF - только синий экран.

Нужно ли менять Windows 10 на 11 из-за 0xEF? Нет. Код один на обеих. Смена поколения не чинит дохлый диск.

Можно ли игнорировать разовый 0xEF? Если больше не повторяется после сбоя питания - да. Серия за день - нет.

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