⚠ CrashDecoder

0xC000021A WINLOGON_FATAL_ERROR

Windows normally survives a user-mode program crashing - that is the entire point of user mode. This code is one of the few exceptions. When Winlogon or the Client Server Run-Time Subsystem fails, Microsoft's position is that security can no longer be guaranteed, so the operating system stops rather than continue in a state it cannot vouch for. In practice this almost always means you cannot reach the desktop at all, so the repair work happens from the recovery environment.

Updated 2026-07-28Stop error - almost always prevents bootAlso written: 0xC000021A, c000021a, STATUS_SYSTEM_PROCESS_TERMINATED, WINLOGON_FATAL_ERROR

What you are looking at

:(

On current Windows:

Your PC ran into a problem and needs to restart. We're just collecting some error info, and then you can restart.

If you'd like to know more, you can search online later for this error: 0xc000021a

On older versions you may instead get the text form, which is worth recognising because it is still widely quoted:

STOP: c000021a {Fatal System Error} The initial session process or system process terminated unexpectedly with a status of 0x00000000 (0xc0000001 0x001003c0). The system has been shut down.

In Event Viewer the matching entries look like this:

Log Name:      System
Source:        BugCheck
Event ID:      1001
Level:         Error

The computer has rebooted from a bugcheck.  The bugcheck was: 0xc000021a (0xffffe38f2c4b1080, 0x00000000c0000005, 0x0000000000000000, 0x0000000000000000).

What the error actually means

Two names circulate for this code and they are not interchangeable. Microsoft's official bugcheck name is WINLOGON_FATAL_ERROR. STATUS_SYSTEM_PROCESS_TERMINATED is the NTSTATUS value that carries the same number, and it is what Microsoft's own support articles use. Most of the web only ever shows the second one, which is why the parameter table below is so rarely published correctly.

The number itself is a clue to what is going on. Ordinary bugchecks are small values written as 0x0000003B or 0x000000EF. This one is an NTSTATUS error code in the 0xC0000000 range - the same family as 0xC0000005 access violation - because it did not originate in the kernel at all. It started as a user-mode process dying, and the kernel adopted the status as its own.

What makes it fatal is specifically security. Microsoft's wording is that a user-mode subsystem such as WinLogon or CSRSS has been fatally compromised and security can no longer be guaranteed. Windows cannot run without them, so the system switches to kernel mode and stops. It is one of the few cases where a user-mode failure takes the whole machine down.

Reading the parameters

These are unusual, and worth reading carefully because they do not follow the pattern of most stop codes. Parameter 1 is not a pointer to an object - it is a pointer to text.

ParameterWhat it holds
1A string that identifies the problem. Genuinely a string, which is rare among bugcheck parameters. In a debugger it can be read directly, and it frequently names the failing component more plainly than any amount of stack analysis would.
2The error code. The status the failing process died with. Commonly an NTSTATUS value - 0xC0000005 for an access violation inside the process, for example - and it tells you how it died rather than which one it was.
3Reserved.
4Reserved.

What actually triggers it

Microsoft's documented causes are narrower than the general-purpose lists you will find elsewhere, and they cluster heavily around system files being wrong rather than hardware being broken.

CauseHow oftenDetail
Mismatched system filesCommonMicrosoft names this explicitly. System binaries from different builds, or a component store that no longer matches the files on disk, leaves Winlogon or CSRSS unable to start correctly. This is the single most characteristic cause of this code.
A failed update or service pack installationCommonAn update that stops partway - power loss, a forced reboot, a disk error mid-write - produces exactly the mismatch above. Crashes that begin on the first boot after an update point straight here.
A backup restore that skipped files in useOccasionalAlso named directly by Microsoft, and easy to overlook. Some backup programs decline to restore system files they detect as in use, so the restored system is internally inconsistent from its first boot. If this started right after restoring an image, check for an updated version of the backup software.
An incompatible third-party applicationOccasionalBecause the failure is in user mode, third-party software is a more plausible culprit here than on most stop codes. Anything that hooks the logon process or the security subsystem - anti-virus, endpoint agents, credential providers, VPN clients - is a candidate.
A user-mode device driver or system serviceOccasionalMicrosoft groups these with applications for this code, because the failure is happening in a user-mode process either way. A recently installed or updated one is the thing to remove first.
MalwareOccasionalRelevant because the affected processes are exactly the ones malware targets. Microsoft's own remarks recommend a virus scan that includes the Master Boot Record.
Failing storageRareNot on Microsoft's list, but a drive that cannot reliably return system files produces the same mismatch by a different route. Worth checking if repairs keep undoing themselves.

Narrowing it down

The first thing to understand is that the usual debugging approach does not work here, which saves you a lot of wasted effort.

Do not start with the kernel debugger

Microsoft is unusually direct about this: running the kernel debugger may not be useful in this situation because the actual error occurred in a user-mode process. A kernel dump of a user-mode failure has limited value, because the data you want is frequently paged out and simply not present in the dump.

If you do open a dump, read parameter 1 as a string rather than chasing the stack. That string is the intended diagnostic here, and it is the part almost everyone skips.

What it tells you

This is the opposite of the advice for most stop codes on this site, and following the usual routine here wastes an evening. The productive work is repairing system files, not analysing a dump.

Get into the recovery environment

Since you almost certainly cannot boot, everything below runs from recovery. Power the machine on and hold the power button to kill it as soon as the Windows logo appears. Three times in a row, and the fourth boot enters recovery automatically. Then Troubleshoot, Advanced options.

If recovery itself will not load, boot from Windows installation media and choose Repair your computer rather than Install.

What it tells you

If Safe Mode works but normal boot does not, a third-party service or driver is loading and killing the logon process - which makes the strip-back fix below the fastest route.

Establish what changed immediately before

This code has a strong tendency to follow a specific event rather than appear spontaneously. Work backwards: was there an update, a restore from backup, a new security product, a driver install?

If you can reach Windows at all, sort installed programs by install date in Uninstall or change a program, and check the System log in Event Viewer for critical errors in the same time window as the crash.

What it tells you

An identifiable change immediately beforehand is the most valuable finding available for this code, because it usually converts the problem from a repair job into an uninstall.

Confirm the drive letters before running anything

In the recovery environment your Windows installation is frequently not on C:. The recovery image is usually X:, and Windows often appears as D:. Run diskpart, then list volume, then exit, and use what you actually see.

What it tells you

Every offline command below targets a specific drive. Running them against the wrong one reports success and repairs nothing, which is a common and demoralising way to lose an hour.

Fixes, cheapest first

Ordered by effort. Most of these run from the recovery environment, using the drive letters you confirmed above.

  1. Check whether the drive is encrypted first

    Effort: 5 minutes · Risk: Low

    Before doing anything in recovery, find out whether BitLocker or Device Encryption is on. If it is, recovery will ask for a 48-digit recovery key and you will not get past that screen without it.

    From a working Windows on another machine, sign in at account.microsoft.com/devices/recoverykey to retrieve it. If you can still reach this machine's desktop, check status with:

    manage-bde -status
    Watch out

    Device Encryption is on by default on many consumer laptops without the owner ever enabling it, so do not assume it is off because you never turned it on. Retrieve the key before you need it, not after.

  2. Repair system files offline

    Effort: 45 minutes · Risk: Low

    This is the highest-value fix for this code specifically, because mismatched system files are its most characteristic cause. Microsoft's own remarks lead with the System File Checker.

    From recovery, using your confirmed drive letters:

    sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows

    If you can reach Windows, run these in an administrator terminal in order instead:

    sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
    Watch out

    The second sfc run is not redundant. DISM repairs the component store that sfc draws its replacement files from, so running sfc again afterwards can fix files the first pass could not.

  3. Uninstall the most recent update

    Effort: 20 minutes · Risk: Low

    If this started after an update - and with this code it often did - remove it. From recovery: Troubleshoot, Advanced options, Uninstall Updates, which offers the latest quality update and the latest feature update as separate choices. Try the quality update first.

  4. Boot into Safe Mode and strip back software

    Effort: 30 minutes · Risk: Low

    Microsoft recommends Safe Mode explicitly for this code, and it is more useful here than usual because the culprit is in user mode. Safe Mode loads only the minimum drivers and services, so if the machine boots that way, something optional is responsible.

    From recovery: Troubleshoot, Advanced options, Startup Settings, Restart, then choose option 4, 5 or 6.

    Once in, remove third-party anti-virus and endpoint agents, VPN clients, and anything installing a credential provider or hooking logon. Then reboot normally.

    Watch out

    On some machines Safe Mode is also reachable by pressing F8 at boot, but this is manufacturer-dependent and disabled by default on modern fast-boot systems.

  5. Run System Restore

    Effort: 30 minutes · Risk: Low

    Because this code so often follows a specific change, rolling back to a restore point from before that change is unusually likely to work. From recovery: Troubleshoot, Advanced options, System Restore.

    Pick the most recent point that predates the first crash, not simply the most recent point available.

    Watch out

    This only helps if System Protection was enabled beforehand. If no restore points exist, move on rather than trying to create one now.

  6. Scan for malware offline

    Effort: 1 hour · Risk: Low

    Microsoft's remarks call for a virus scan and specify that it should check the Master Boot Record, not just the file system. An offline scanner runs before Windows loads, so it can see what a scan from inside a running system cannot.

    If you can boot, use Windows Security, Virus and threat protection, Scan options, Microsoft Defender Offline scan. If you cannot, build rescue media from another machine.

  7. Repair install without losing files

    Effort: 1-2 hours · Risk: Medium

    An in-place upgrade replaces every system file while keeping applications, settings and data. For a code whose defining cause is mismatched system files, this is the fix that actually addresses the root problem rather than patching around it.

    1. Download the Media Creation Tool on a working machine and build installation media, or mount the ISO.
    2. Run setup.exe from within Windows - including from Safe Mode if that is all you have. Booting from the media gives you a clean install instead, which is not what you want.
    3. Choose to keep personal files and apps when prompted.
    4. Let it run to completion without interrupting it.
    Watch out

    This needs a bootable Windows to launch from. If nothing boots at all, not even Safe Mode, copy your data off using recovery's command prompt before considering a clean install. Back up first regardless.

When it is the hardware, not Windows

Hardware is a less likely explanation here than for most stop codes, but these signs suggest the storage device is undermining every repair you make:

The first and last are the ones that matter. Mismatched system files are the cause of this code, and a drive that cannot reliably hold what is written to it manufactures that mismatch continuously. Repairing files onto a failing disk looks like it worked and then decays. If a fresh install reproduces the problem on the same drive, replace the drive.

Frequently asked

Is this the same thing as CRITICAL_PROCESS_DIED?

Closely related but distinct, and the difference is worth knowing because it changes what you do. 0xEF CRITICAL_PROCESS_DIED fires when any process marked critical terminates, and the diagnosis depends entirely on which one it was. This code is narrower: it is specifically about the security-critical subsystems, and Microsoft's framing is that security can no longer be guaranteed rather than simply that a process is missing.

Practically, 0xEF sends you looking for the process name in a dump. 0xC000021A sends you to system file repair, because that is its characteristic cause. They overlap in that csrss.exe can trigger either one.

Why is it written c000021a instead of 0x0000021A?

Because it is not a normal bugcheck number. It is an NTSTATUS status code, from the same 0xC0000000 range as 0xC0000005 access violation, and the kernel adopted it from the user-mode process that failed. Ordinary bugchecks are allocated small sequential values; this one was never in that series.

That also explains why searching for it behaves oddly - it is quoted as c000021a, 0xc000021a and 0xC000021A more or less interchangeably, and all three are the same error.

Should I open the dump file in WinDbg?

Lower priority than usual. Microsoft states the kernel debugger may not be useful here because the failure happened in a user-mode process, and a kernel dump of a user-mode fault is often missing the data you need.

If you do open one, read parameter 1 as a string rather than analysing the stack - it is a string that identifies the problem, and it is the most direct information the bugcheck offers. But repairing system files is the better use of your time.

It started right after I restored from a backup image.

Then you have probably found it. Microsoft names this cause directly: some backup programs skip restoring system files they detect as in use, leaving the restored installation internally inconsistent. The restore looked successful and produced a system whose files do not match each other.

Check for an updated version of the backup software from its manufacturer, then repair system files using the steps above - or restore again with a program that handles in-use files correctly.

Can I stop it happening so I can at least get in and fix it?

No, and unlike some stop codes there is no override to disable. Windows is refusing to run without a trustworthy security subsystem, and there is no degraded mode to fall back to - a session with no Winlogon has nothing to log you into.

Safe Mode is the closest thing to a way in, because it loads fewer components and so may avoid whatever is killing the process. If Safe Mode works, use it rather than trying to force normal boot.