How to Fix the CRITICAL_PROCESS_DIED Blue Screen on Windows 11

The CRITICAL_PROCESS_DIED stop code (bug check 0x000000EF) appears when a process Windows depends on terminates unexpectedly. Microsoft's debugger documentation lists the usual victims: csrss.exe, wininit.exe, winlogon.exe, smss.exe, services.exe, and logonui.exe. Windows cannot continue safely once one of these dies, so it crashes to protect your data. The root cause is almost always corrupt system files, a bad driver, or failing hardware. Here is how to isolate it methodically instead of guessing.

Key takeaways

• The crash points to a dead critical system process, not the process itself being broken, something underneath it (a driver, file, or memory) failed.
• SFC and DISM repair the most common cause: corrupt system files. Run them first.
• A minidump opened in WinDbg with !analyze -v names the exact failing module, turning guesswork into a targeted fix.
• If software repairs do not stick, suspect bad RAM or a failing SSD, the two most overlooked causes.
• A full Windows reset is the last resort, not the first move.

First: can you boot normally?

Your approach depends on whether Windows starts.

• If you can reach the desktop (the crash is intermittent), work through the fixes below in order.
• If you're in a boot loop, force three failed boots to trigger Automatic Repair, then go to Troubleshoot > Advanced options and use Safe Mode or Startup Repair to run the same steps.

Before you start, use this table to read the clues and pick the most likely cause first:

Clue	Likely cause	Where to focus
Stable in Safe Mode	Third-party driver or startup app	Driver review, clean dump
Crashes right after an update	Buggy update or driver	Uninstall update, roll back driver
Random crashes under no pattern	Bad RAM	Memory diagnostic, MemTest86
Started after new app or device	Low-level filter driver	Uninstall recent software
File errors, slow boot, freezes	Failing SSD	chkdsk, CrystalDiskInfo SMART check
Crashes only under heavy load	Overheating or unstable overclock	Reset overclock, check temps

Step 1: Boot into Safe Mode

Safe Mode loads a minimal set of drivers, so if the crash stops there, a driver or background app is the cause.

1. From WinRE, choose Advanced options > Startup Settings > Restart.
2. Press 5 (or F5) for Safe Mode with Networking.

If the system is stable in Safe Mode, the problem is almost certainly a third-party driver or startup program rather than core hardware.

Step 2: Repair system files

Corrupt system files are the single most common cause. From an elevated Command Prompt (or in Safe Mode):

sfc /scannow

If SFC reports it couldn't fix everything, repair the component store first, then re-run SFC:

dism /online /cleanup-image /restorehealth
sfc /scannow

Restart and watch for the crash. These same two commands are the backbone of most Windows repair workflows, they also appear in our walkthrough for the INACCESSIBLE_BOOT_DEVICE blue screen.

Step 3: Read the crash dump to name the culprit

Rather than updating drivers at random, let Windows tell you which module failed.

1. Install WinDbg (from the Microsoft Store, as part of the Windows SDK).
2. Open the most recent dump in C:\Windows\Minidump\. A full dump, if enabled, lives at C:\Windows\MEMORY.DMP.
3. Run the analysis command:

!analyze -v

The output names the module that triggered the crash. Check the second bug-check parameter too: if it is 0, a process died (often a system-file or malware issue); if it is 1, a thread died (more often a driver). Examine two or three dumps, if the same module name keeps appearing, you have found your offender.

Step 4: Update or roll back the offending driver

Armed with a module name (or, failing that, a yellow warning icon in Device Manager):

• Open Device Manager and update any device flagged with a warning.
• If the BSODs began right after a driver update, open that device's Properties > Driver tab and click Roll Back Driver.
• Pay special attention to graphics, storage, and chipset drivers, which run at a low level and can take down critical processes. Low-level tools added recently, antivirus, VPN clients, disk utilities, overclocking apps, are also frequent triggers; uninstall anything installed around when the crashes began.

Step 5: Test your RAM

Unstable memory causes random kernel-process crashes that look exactly like this.

1. Press Win + R, type mdsched.exe, press Enter.
2. Choose Restart now and check for problems.
3. Let the Windows Memory Diagnostic run a full pass.

For a more thorough test, run MemTest86 from a USB stick overnight. Any errors point to a failing module, reseat or replace it.

Step 6: Check drive health

A failing SSD corrupts boot and system files as they're written.

• Run chkdsk C: /f /r from an elevated prompt (it schedules on next reboot). If you have also seen the disk pinned at 100%, our guide to 100% disk usage on Windows 11 covers the same drive-health checks.
• Check SMART data with a tool like CrystalDiskInfo. A "Caution" or "Bad" health status means the drive is failing and should be replaced.

Step 7: Uninstall a recent update or use System Restore

A failed or buggy Windows update can introduce this BSOD.

1. Open Settings > Windows Update > Update history > Uninstall updates.
2. Remove the most recent quality update and restart.

If you can't boot, do the same from WinRE > Advanced options > Uninstall Updates. When crashes are recent and you have a restore point, WinRE > Advanced options > System Restore rolls the system back to a stable configuration without deleting personal files, often undoing the driver or update at fault in one step.

Frequently asked questions

Does CRITICAL_PROCESS_DIED mean my hardware is failing?

Not necessarily. Most cases trace to corrupt system files or a bad driver, both of which are software fixes. Hardware (RAM or an SSD) is the cause when the crash persists after a clean SFC/DISM run and a driver review, which is why memory and drive tests come after the software steps.

Can malware cause this blue screen?

Yes. Malware that tampers with or kills a critical system process can produce this exact stop code. After repairing system files, run a full scan with Windows Security or Microsoft Defender Offline before concluding it is a hardware fault.

What if it only crashes during gaming or heavy load?

Load-dependent crashes usually point to overheating, an unstable overclock, or a power-delivery problem rather than a software bug. Reset any overclock to stock, check temperatures, and test the RAM at its rated speed.

Where exactly are the crash dump files?

Small dumps default to C:\Windows\Minidump\ with a .dmp extension per crash. A full kernel dump, if enabled, is C:\Windows\MEMORY.DMP. Open either in WinDbg and run !analyze -v.

What to do right now

If you are facing this crash, work the list in order and stop when the BSODs end:

• Boot into Safe Mode. If it is stable there, the cause is a third-party driver or startup app, not core hardware.
• Run sfc /scannow, and if it cannot fix everything, run dism /online /cleanup-image /restorehealth then SFC again.
• Open the newest minidump in C:\Windows\Minidump\ with WinDbg and run !analyze -v to name the failing module.
• Update or roll back that driver, focusing on graphics, storage, and chipset drivers and anything installed recently.
• If it persists, test RAM with Windows Memory Diagnostic or MemTest86, and check drive health with chkdsk and CrystalDiskInfo.
• Only after all of that fails should you consider System Restore or, as a last resort, a full reset.

Quick recap

Boot to Safe Mode to confirm it's software, repair system files with SFC and DISM, then read a minidump in WinDbg to name the failing module and update or roll back that driver. If crashes persist, test RAM and drive health, those hardware failures are the most overlooked cause of CRITICAL_PROCESS_DIED.