⚠ CrashDecoder

0x000000EF CRITICAL_PROCESS_DIED

Windows marks a small number of processes as critical. If one of them exits for any reason, the operating system has no way to continue and stops immediately. What makes this code different from most is where it leaves you: frequently in a reboot loop that never reaches the desktop, which means the repair work happens from the recovery environment rather than from Windows.

Updated 2026-07-27Stop error - frequently a boot loopAlso written: 0xEF, CRITICAL PROCESS DIED, critical_process_died, critical process died boot loop

What you are looking at

:(

Your PC ran into a problem and needs to restart.

Stop code: CRITICAL_PROCESS_DIED

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: 0x000000ef (0xffffa50c1d2e4080, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000).

What the error actually means

A handful of user-mode processes are load-bearing for the whole system. csrss.exe handles console and window management on behalf of the kernel. wininit.exe and winlogon.exe run session startup and logon. services.exe manages every Windows service. lsass.exe holds the security subsystem. smss.exe is the session manager.

These are flagged as critical processes. If one terminates - cleanly or otherwise - Windows cannot fall back to a degraded mode, because there is no meaningful system left without them. It bugchecks instead.

So the stop code tells you the outcome, not the reason. The useful question is always which process died and why it was allowed to, and the answers span corrupt system files, failing storage, a bad update and malware.

Reading the parameters

Two of the four carry information. The process name itself comes from the dump rather than the parameter list.

ParameterWhat it holds
1The process object. Not human-readable on its own, but a debugger turns it into a name - and that name is the whole diagnosis.
2If 0, a process terminated. If 1, a thread terminated. This decides which debugger command to use next: !process for a process, !thread for a thread. A dying thread inside an otherwise healthy critical process is a meaningfully different situation from the whole process exiting.
3Reserved.
4Reserved.

What actually triggers it

Which cause is likely depends heavily on which process died, so treat this list as a starting distribution rather than a ranking that applies to your case.

CauseHow oftenDetail
Corrupt system filesCommonThe most frequent cause by some margin, and unlike most stop codes that is genuinely true here rather than a reflex answer. A damaged system binary or a broken component store leaves a critical process unable to start or unable to continue.
Failing storageCommonIf the drive cannot reliably return the files these processes need, they die. A drive developing bad sectors in the wrong place produces this repeatedly and gets worse quickly.
A bad or interrupted Windows updateOccasionalAn update that fails partway leaves mismatched system components. Crashes that begin immediately after an update, particularly after a power loss during one, point straight here.
Third-party drivers and security softwareOccasionalAnti-virus products interact directly with lsass.exe and services.exe. A version mismatch after an update can terminate them.
A third-party service set to restart the computer on failureOccasionalUnder-known and worth checking. Microsoft notes that a developer can create a service and set its recovery option to Restart the Computer. A service configured that way which keeps failing will keep taking the machine down, and it will look like a Windows fault rather than a badly configured application. Check the Recovery tab in the properties of any recently installed service.
MalwareOccasionalMore relevant here than on most stop codes, since some malware attacks or injects into exactly these processes - and some poorly written malware simply crashes them.
Failing RAMRarePossible, but if memory were the problem you would normally see other stop codes alongside this one.

Narrowing it down

The first question is whether you can reach the desktop at all, because that determines which tools you have.

Establish whether you can boot

If Windows starts normally and crashes occasionally, you have full access and can work from there. If it loops, interrupt the boot three times with the power button to trigger the recovery environment, then choose Troubleshoot, Advanced options.

From there, Startup Settings gives you Safe Mode, and Command Prompt gives you offline repair tools.

What it tells you

Booting into Safe Mode successfully but not normally implicates a driver or a startup service rather than core system corruption - the critical processes clearly can run.

Find out which process died

If you can reach Windows, open the newest minidump in WinDbg and run !analyze -v. Look for PROCESS_NAME, then check parameter 2 - 0 for a process, 1 for a thread - and follow with !process or !thread accordingly.

Check for a user dump first

Microsoft notes that in many cases a user-mode dump is written before the system bugchecks, and that when one exists it should be examined first - debugging user-mode code from a kernel dump is limited by paged-out data. Look in C:\Windows\LiveKernelReports and in the per-user crash dump location under %LOCALAPPDATA%\CrashDumps before settling for the kernel dump.

What it tells you

Microsoft's documented list of built-in critical services is csrss.exe, wininit.exe, logonui.exe, smss.exe, services.exe, conhost.exe and winlogon.exe. csrss.exe is the broadest and least specific. services.exe suggests a service or its driver. Knowing the name narrows a wide field considerably.

Check the drive before anything else

Given how often storage is behind this, check it early. From a working Windows, read SMART data with CrystalDiskInfo. From recovery, run chkdsk C: /f - noting that the drive letter in recovery is often not C, so use diskpart and list volume to confirm first.

What it tells you

Reallocated or pending sectors, or an SSD reporting degraded health, moves storage to the front of the queue and makes the software repairs below temporary at best.

Fixes, cheapest first

If you are in a boot loop, everything here runs from the recovery environment. Reach it by interrupting boot three times.

  1. Repair system files

    Effort: 45 minutes · Risk: Low

    From a working Windows, run these in an administrator terminal in order:

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

    From the recovery environment, the offline form is different and the drive letters usually are not what you expect. Confirm them with diskpart and list volume first, then:

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

    In recovery, the Windows installation is often on D: while the recovery image is on X:. Running these against the wrong drive does nothing useful and wastes a lot of time - check first.

  2. Check and repair the disk

    Effort: 30 minutes to hours · Risk: Low

    Run chkdsk C: /f /r against the Windows volume. The /r option locates bad sectors and takes considerably longer, but on a drive suspected of failing it is the point of the exercise.

    Watch out

    If the drive is genuinely failing, chkdsk can accelerate the failure while it works. Image the drive first if the data matters and you have not backed it up.

  3. Uninstall the most recent update

    Effort: 20 minutes · Risk: Low

    If the crashes started after an update, remove it. From recovery: Troubleshoot, Advanced options, Uninstall Updates - which offers the latest quality update and the latest feature update separately.

    From a working Windows, use Settings, Windows Update, Update history, Uninstall updates.

  4. Boot into Safe Mode and strip back software

    Effort: 30 minutes · Risk: Low

    If Safe Mode works, use it to remove third-party anti-virus, VPN clients and anything else that installs kernel drivers or hooks into the security subsystem. Then reboot normally.

    This is the fastest route when lsass.exe or services.exe is the process that died.

  5. Scan for malware offline

    Effort: 1 hour · Risk: Low

    Because this stop code involves processes malware specifically targets, an offline scan is worth more here than on most codes. Microsoft Defender Offline runs before Windows loads, so it can see things a normal scan cannot.

    From Windows Security, choose Virus and threat protection, Scan options, Microsoft Defender Offline scan.

  6. Repair install without losing files

    Effort: 1-2 hours · Risk: Medium

    An in-place upgrade replaces every system file while keeping your applications, settings and data. It is the strongest software repair available short of a clean install, and it resolves corruption that sfc and DISM cannot.

    1. Download the Media Creation Tool and build installation media, or mount the ISO from a working Windows.
    2. Run setup.exe from within Windows - not from a boot to the media.
    3. Choose to keep personal files and apps when prompted.
    4. Let it complete without interruption.
    Watch out

    This needs a bootable Windows to start from. If you are stuck in a loop, Safe Mode may be enough - but if nothing boots at all, the disk repair steps have to come first. Back up before starting.

When it is the hardware, not Windows

Signals that the storage device is the underlying problem and software repair will not hold:

That last one is decisive. Repairing files on a failing drive is writing to a surface that cannot reliably hold them - the repair appears to work and then decays. If a fresh install reproduces the problem on the same disk, replace the disk rather than the operating system, and copy your data off while it still reads.

Frequently asked

I am stuck in a reboot loop and cannot get to Windows at all. Where do I start?

Force the recovery environment: power the machine on and hold the power button to kill it as soon as you see the Windows logo. Do that three times in a row and the fourth boot goes into recovery automatically. From there, Startup Repair is the low-effort first attempt, and Command Prompt gives you chkdsk and the offline sfc above. If recovery itself will not load, boot from Windows installation media instead and choose Repair your computer.

The dump says csrss.exe. What does that actually tell me?

Less than you would hope. csrss.exe is involved in a great deal of normal activity, so it is the process most likely to be caught up in a problem originating elsewhere. Treat it as confirming the category rather than identifying the cause, and lean on the drive check and system file repair. A more specific name like lsass.exe narrows things far more usefully.

Will a clean install fix this?

It fixes the software cases - corrupt files, a broken update, malware - which is a large share of them. It does nothing if the drive is failing, and that is common enough with this particular stop code that checking SMART data first is worth the ten minutes. Reinstalling onto a dying disk buys you days.

Can I disable the critical process check so it stops crashing?

No, and it would not help if you could. The bugcheck is not the problem - it is Windows noticing that something it depends on absolutely has gone. A system without csrss.exe or services.exe cannot function in any useful way, so there is nothing to continue to.