STATUS_SYSTEM_PROCESS_TERMINATED 0xC000021A and CRITICAL_PROCESS_DIED 0x000000EF

Fix it now

A user-mode process the kernel treats as critical has ended, and Windows stopped rather than continue without it. Microsoft names two causes: a third-party driver, service or application, and mismatched system files – most often after a restore from backup that skipped files it judged to be in use.

diskpart
list volume
exit
sfc /scannow /offbootdir=D:\ /offwindir=D:\Windows
dism /Image:D:\ /Cleanup-Image /RestoreHealth
dism /Image:D:\ /Get-Packages /Format:Table

1. Get into the recovery environment: hold Shift while choosing Restart, or interrupt startup with the power button three times, then Troubleshoot, Advanced options, Command Prompt.
2. Find the real Windows volume with diskpart and list volume before running anything. The recovery environment reassigns letters and it is rarely C:.
3. Read the package list for one installed on the day the failures began, and remove it with dism /Image:D:\ /Remove-Package /PackageName:<full package name>. Only .cab packages can be removed this way; .msu files cannot.
4. If a package is stuck in Install Pending, clear it with dism /Image:D:\ /Cleanup-Image /RevertPendingActions, which Microsoft supports only against an offline image.
5. Restart. If it still stops, go to Advanced options, Startup Settings and boot Safe Mode, then remove whatever was installed most recently.

On a BitLocker-protected machine none of this is available without the 48-digit recovery key. Retrieve it from the Microsoft account, Entra ID or Active Directory before you start.

If the machine reaches the desktop twice from cold, you are done. If not, the next section explains what the kernel is protecting and how to tell the two documented causes apart.

Why it happens

Windows runs a small group of processes the rest of the system assumes will always be there. Microsoft names them: csrss.exe, wininit.exe, logonui.exe, smss.exe, services.exe, conhost.exe and winlogon.exe. They run in user mode like any other program, but the kernel marks them critical, because everything already running holds handles into them and there is no supported way to restart one mid-session.

0xC000021A is published as WINLOGON_FATAL_ERROR: the Winlogon process terminated unexpectedly. Microsoft’s stated cause is that a user-mode subsystem such as Winlogon or the Client Server Run-Time Subsystem has been fatally compromised and security can no longer be guaranteed, so the operating system switches to kernel mode and stops. It is one of the few cases where the failure of a user-mode service shuts the machine down.

0x000000EF is the numbered bug check for the same class of event: a critical system process terminated because its state was corrupted or damaged. Its parameters are worth reading correctly, because they are commonly misquoted. Parameter 1 is the process object, not a name. Parameter 2 is what tells you what died – 0 for a process, 1 for a thread. 0x000000F4 is its close relative, a process or thread crucial to system operation exiting unexpectedly, and it is the more helpful of the two on screen because parameter 3 is the process image file name.

The cause most articles miss is Microsoft’s second one. Mismatched system files produce 0xC000021A, and the situation Microsoft describes is restoring a hard disk from a backup where the backup program skipped restoring system files it determined were in use. If this machine was recently restored rather than recently updated, that is where to look, and no amount of update removal will help.

Full reference

Reading the four codes

0x000000F4 is the one to hope for, because it names the image file. If you have a dump for any of the others, the analysis extension will resolve the process object in parameter 1 to a name; without one, the pattern of when the failure occurs is what you have.

Narrowing it before you start repairing

Working offline without breaking anything

1. Establish the Windows volume letter every single time. Recovery reassigns letters between boots, so a letter that was right an hour ago may not be now.
2. Run the read-only commands first – /Get-Packages, /Get-Drivers, sfc with /verifyonly where available – and write down what you find before you change anything.
3. Make one change, then restart. Two changes at once turns a diagnosis into a guess.
4. Keep a note of every package and driver removed, so the machine can be returned to a supported state afterwards.
5. Reapply the updates you removed once the machine is stable, one at a time, so you know which one was the problem.

When a profile rather than the system is broken

If the stop arrives at or just after the sign-in screen, and other accounts sign in normally, the system is intact and one profile is not. System Restore from the recovery environment is the cleanest route because it replaces the registry hives as part of the restore. Where only one profile is affected, sign in with another administrator account and create a fresh profile rather than repairing the broken one – it is faster and it leaves you with a known state.

Before you uninstall updates, remove drivers or run System Restore, make sure you can unlock the drive. On a BitLocker-protected machine the recovery environment asks for the 48-digit recovery key, and without it none of these steps exist. Retrieve it from the Microsoft account, Entra ID or Active Directory first.

If the stop code changes between attempts, stop repairing software. Run mdsched.exe from a working session, check drive health with the manufacturer’s utility, and on a server read the management controller log for memory and storage faults before going further.

When nothing offline works

An in-place repair upgrade rebuilds every Windows component while leaving applications, settings and data alone. Mount media matching the current edition and build, run setup from within Windows, and choose to keep files and apps. It needs the machine to start far enough to run setup, which is exactly what this fault often prevents – so it is the step after Safe Mode, not before it. A reset comes after that, and a clean install after that.

Every code this article covers

Confirm the fix worked

1. Restart twice, including one full power off rather than a restart, and confirm both reach the desktop.
2. sfc /scannow from an elevated prompt in the running system reports no integrity violations.
3. No new BugCheck event with ID 1001 appears in the System log after the repair.
4. C:\Windows\Minidump gains no new dump files after a day of normal use.
5. Any update you removed reinstalls cleanly, or you know which one to keep held back and why.

Questions people ask about this