CRITICAL_PROCESS_DIED: как найти завершившийся процесс Windows

При CRITICAL_PROCESS_DIED нужно установить две вещи: какой критический объект завершился и что происходило перед этим. Код остановки 0xEF сообщает о завершении критического процесса или потока, но сам по себе не определяет виновный драйвер, приложение или накопитель. Для поиска причины понадобятся обстоятельства повторения, события Windows и, по возможности, дамп памяти.

Если параллельно выбираете лицензию, сравнивайте Windows 11 Home и Windows 11 Pro по необходимым возможностям редакции. Код 0xEF не указывает на необходимость перехода с Home на Pro. Покупка другой лицензии не устраняет причину завершения системного процесса.

Что различает второй параметр ошибки 0xEF

У этой остановки есть важное уточнение: второй параметр проверки ошибки показывает тип завершившегося объекта. Значение 0 означает процесс, значение 1 — поток. Это сведения для разбора дампа; по одной надписи CRITICAL_PROCESS_DIED на экране нельзя уверенно выбрать нужную ветку.

Если в разборе встречаются названия csrss или wininit, воспринимайте их как диагностические сведения. Имя завершившегося процесса не равно причине его завершения. Оно не даёт оснований завершать такой процесс вручную, удалять его исполняемый файл или подменять файл копией с другого компьютера.

Если код ещё не удалось зафиксировать, используйте инструкцию по сохранению stop code при BSOD. Здесь дальнейшая проверка относится именно к подтверждённой остановке 0xEF.

Как получить доступ, прежде чем что-либо исправлять

Сначала скопируйте важную работу, если Windows ещё позволяет это сделать. Сохраните документы до отката драйвера или удаления приложения. При признаках проблем с чтением диска приоритетом остаётся сохранение доступных данных: серия изменений системы затруднит выяснение исходной причины.

Если рабочий стол недоступен, используйте параметры загрузки в среде восстановления Windows — WinRE. В Windows 11 нужная последовательность: «Поиск и устранение неисправностей» → «Дополнительные параметры» → «Параметры загрузки», затем перезапуск и выбор безопасного режима. Если накопитель защищён BitLocker, заранее подготовьте ключ восстановления: он может понадобиться для доступа.

Windows 11 для восстановленного компьютера Home и Pro выбирают по нужным функциям и имеющемуся праву на систему. Завершение критического процесса сначала диагностируют; новый ключ не устраняет причину остановки.

Windows 11 Pro

1 790 ₽ 2 920 ₽

Добавить в корзину

Windows 11 Home

1 690 ₽ 2 250 ₽

Добавить в корзину

Безопасный режим нужен для получения доступа и проверки обстоятельств сбоя. Его успешный запуск ещё не доказывает неисправность конкретного драйвера. Если попасть в Windows или WinRE не получается, не начинайте сброс наугад: сначала нужно решить вопрос доступа к данным и диагностическим материалам.

Чем отличаются остановка при входе и случайные падения

Запишите момент появления ошибки и действие перед ней. Для 0xEF полезно разделить три сценария, поскольку они требуют разных проверок:

• Повторение при входе в систему. Уточните, возникает ли остановка до появления рабочего стола или сразу после входа. Сравните обычную загрузку с доступом через безопасный режим, не объявляя приложение виновным только по совпадению времени.
• Начало после обновления драйвера. Запишите конкретное устройство, какой драйвер менялся и когда. Факт обновления создаёт проверяемую гипотезу, но не доказывает причинную связь.
• Нерегулярные падения с признаками проблем накопителя. Отдельно отмечайте ошибки чтения, недоступность файлов или исчезновение диска. Такие наблюдения требуют проверки накопителя, а не последовательного удаления всех недавно установленных программ.

Для каждого повтора сохраняйте время и одинаково описывайте условия. Формулировка «после ввода пароля, до появления рабочего стола» полезнее записи «иногда синий экран». Если обстоятельства различаются, не объединяйте их преждевременно в одну причину.

Как связать завершившийся процесс с событиями перед сбоем

Нажмите Win + R, введите perfmon /rel и нажмите Enter: откроется история надёжности. Затем найдите через поиск Windows «Просмотр событий» и откройте «Журналы Windows» → «Система» и «Приложение». Найдите время остановки и просмотрите записи непосредственно перед ним. Событие, зарегистрированное после перезапуска, может описывать уже последствия сбоя. Самая заметная ошибка в списке не обязательно объясняет завершение критического процесса.

Сопоставьте записи с выбранным сценарием: входом в систему, изменением драйвера или проблемами чтения. Отмечайте источник события, время и текст сообщения. Если перед несколькими остановками повторяется одна последовательность, это полезная зацепка для проверки, но пока ещё гипотеза.

Сохраните имеющиеся минидампы отдельно и передавайте их приватно. При анализе дампа сначала подтверждают код 0xEF и значение второго параметра, затем выясняют, какой процесс завершился или к какому процессу относился завершившийся поток. Возможность установить это зависит от сохранённых данных; одного минидампа может оказаться недостаточно для вывода о причине.

При сохранении малых дампов проверьте папку %SystemRoot%\Minidump. Отсутствие файла не отменяет сам сбой: запись зависит от настроек и возможности Windows сохранить данные. Откройте имеющийся дамп в WinDbg через Open dump file. В командной строке именно отладчика выполните:

!analyze -v

Сначала сверьте BugCheck и аргументы. Для 0xEF значение Arg2 определяет, к чему относится адрес Arg1: процессу или потоку. Специалист изучает этот объект расширением !process либо !thread; адрес берут из конкретного дампа. Имя в сводке анализа — зацепка, а не доказательство вины приложения.

Если разбор выполняет специалист, попросите разделить установленное имя объекта, события перед остановкой и предположение о виновном компоненте. Это поможет избежать замены системного файла на основании одного названия.

Как проверить связь с одним недавним изменением

Меняйте только один подтверждённый фактор. Если начало повторяющихся остановок совпало с обновлением конкретного драйвера, рассмотрите его штатный откат, когда он доступен. Если подтверждено изменение определённого приложения, отменяйте именно его. Перед действием сохраните сведения о текущем состоянии, чтобы результат можно было сопоставить с исходным.

Когда установленная перемена — обновление Windows, следующий шаг описан в руководстве по BSOD после обновления Windows 11. Не переносите этот сценарий автоматически на любое появление 0xEF.

Не подменяйте проверку массовой чисткой реестра, заменой системных EXE или включением Driver Verifier сразу для всех драйверов. Проверка целостности файлов также требует отдельного основания; имя завершившегося процесса само по себе его не даёт.

Когда результат можно считать подтверждённым

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

Если 0xEF возвращается, сохраните новые материалы и остановите перебор исправлений без основания. Для передачи специалисту подготовьте код, время повторов, описание момента падения, сведения о единственном отменённом изменении, относящиеся к нему события и доступные дампы. Отдельно укажите, запускается ли безопасный режим и есть ли признаки ошибок накопителя.

Такой набор позволяет продолжить поиск причины завершения процесса и проверить уже сформулированные гипотезы, сохранив связь между наблюдением, действием и результатом.