Diagnose and recover from a CRITICAL_PROCESS_DIED startup loop

Windows repeatedly stops during startup with CRITICAL_PROCESS_DIED. The bug check means a process required for Windows integrity terminated or became corrupted. It is a symptom category, not a single repair: the underlying cause may be a driver, failed servicing action, damaged protected file, storage error, memory instability, or a specific OEM service.

Searchable Windows error codes and exact messages

Search CRITICAL_PROCESS_DIED 0xEF with the exact process, module, driver, update KB, or storage/memory result. ntoskrnl.exe alone usually identifies where Windows detected the crash, not the component that caused it.

Use this decision procedure when Windows repeatedly stops with 0xEF during startup and no specific underlying mechanism has yet been demonstrated.

Do not keep this generic classification after a dump, named driver, OEM component, checksum error, file-system failure, or memory/storage test identifies a narrower cause. Move to that specific writeup.

The exact Windows build and process name may remain unknown during the first reversible steps. An exact build becomes necessary for matched-source component repair. A specific driver/service must be known before offline disablement or package removal.

• Windows Recovery Environment or installation media
• Command Prompt
• Safe Mode if available
• Storage for copies of crash dumps and logs
• Restore point, update rollback, or matching repair media for the relevant branch

Open Repair your computer > Troubleshoot > Advanced options. The goal is first to preserve evidence and determine whether Safe Mode changes the result.

1. Record the exact CRITICAL_PROCESS_DIED screen and the first event preceding it.

2. Select Startup Settings > Restart > Disable automatic restart after failure if the screen disappears too quickly to record.

3. Return to Startup Settings and try Safe Mode.

4. If Safe Mode starts:

   • copy the newest minidump or MEMORY.DMP;
   • record Update History;
   • record recently installed drivers and applications;
   • inspect Reliability Monitor and Event Viewer around the first crash;
   • do not run cleanup utilities that remove dumps or logs.

5. If Safe Mode fails, open WinRE Command Prompt and map the Windows volume:

   diskpart
   list volume
   select volume <Windows-volume-number>
   detail volume
   assign letter=W
   exit
   

6. Inspect available evidence:

   dir W:\Windows\Minidump
   dir W:\Windows\MEMORY.DMP
   dir W:\Windows\Logs\CBS\CBS.log
   dir W:\Windows\Logs\DISM\dism.log
   dir W:\Windows\System32\LogFiles\Srt\SrtTrail.txt
   

7. Copy dumps and logs to a detected USB volume before destructive recovery. Replace U: with the detected USB letter:

   md U:\CriticalProcessEvidence
   copy W:\Windows\Minidump\*.dmp U:\CriticalProcessEvidence
   copy W:\Windows\MEMORY.DMP U:\CriticalProcessEvidence
   copy W:\Windows\Logs\CBS\CBS.log U:\CriticalProcessEvidence
   copy W:\Windows\System32\LogFiles\Srt\SrtTrail.txt U:\CriticalProcessEvidence
   

8. Classify the evidence:

   • Safe Mode works: third-party driver, service, security software, or normal-mode startup component is more likely.
   • Crash began during an update: servicing rollback is more likely.
   • Dump names one third-party driver: use the boot-start-driver procedure.
   • Dump/process evidence identifies OEM recovery software: use the specific OEM-service condition.
   • Disk errors, in-page errors, or changing damaged files appear: storage takes priority.
   • Different stop codes and file corruption appear: memory stability takes priority.

Proceed in order and stop when a branch restores stable startup.

Branch A — Use System Restore

1. Select Advanced options > System Restore.
2. Choose a restore point created before the first 0xEF crash.
3. Review affected applications and drivers.
4. Complete the restore and restart twice.

Branch B — Remove the update that immediately preceded the loop

1. Select Advanced options > Uninstall Updates.
2. Use Uninstall latest quality update for a monthly update.
3. Use the feature-update rollback option only when a version upgrade was the trigger and the option is available.
4. Restart and record the result.

Branch C — Remove a demonstrated third-party cause from Safe Mode

1. In Safe Mode, record the exact driver, service, or application version installed immediately before the crash.
2. Roll back the implicated device driver in Device Manager or uninstall the owning application through Installed apps.
3. Do not delete a SYS file manually.
4. Restart normally.

Branch D — Repair Windows files when the storage path is stable

1. From WinRE, run a read-only file-system check:

   chkdsk W:
   

2. If CHKDSK reports logical errors and the drive is stable, back up needed data, then run:

   chkdsk W: /f
   

3. Run offline SFC:

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

4. Record both results and restart.

5. If SFC requires external content, use FIX-018's matching-source procedure.

Branch E — Revert a proven pending servicing operation

Use this only when the crash began during servicing and package inspection shows pending state.

1. List package states:

   dism /image:W:\ /get-packages /format:table
   

2. If unresolved pending packages are present, preserve CBS.log and dism.log.

3. Revert pending actions:

   dism /image:W:\ /cleanup-image /revertpendingactions
   

4. Restart and inspect Update History after recovery.

Branch F — Repair from a working Safe Mode desktop

If Safe Mode works but no specific component is found:

1. Open an administrator Command Prompt.

2. Repair the running component store:

   DISM /Online /Cleanup-Image /RestoreHealth
   

3. After DISM completes successfully, run:

   sfc /scannow
   

4. Perform a clean boot while recording every disabled third-party service and startup item.

5. Restart normally. If the crash stops, re-enable items in groups until the responsible component is isolated.

• System Restore or update removal fixes the loop: Preserve the exact reverted state and do not immediately repeat it.
• Safe Mode removal of one driver/application fixes normal startup: Reinstall only a compatible version.
• CHKDSK/SFC repairs restore startup: Continue storage and integrity monitoring; repeated corruption is evidence of an unresolved cause.
• Pending-action reversion works: Preserve servicing logs and the failed update code.
• The dump identifies a specific third-party module: Stop using this generic writeup and apply the specific driver/service repair.
• The crash returns with different codes or changing file names: Test RAM, storage, power, and firmware defaults before more Windows repairs.
• No branch changes the result: A dump must be analyzed; Reset/reinstall should not erase the evidence before it is copied.

• Do not rebuild BCD solely because CRITICAL_PROCESS_DIED occurs during boot.
• Do not treat ntoskrnl.exe as the culprit without stack or module evidence.
• Do not disable random services or drivers offline.
• Do not run /RevertPendingActions without a failed servicing event and pending package evidence.
• Do not repeatedly repair files while RAM or storage tests fail.
• Do not delete crash dumps, CBS logs, DISM logs, or SrtTrail before copying them.
• Do not reset or reinstall Windows before preserving needed data and diagnostic evidence.

System Restore can usually be undone from Windows or WinRE. Reinstall a removed driver or application only from a verified compatible package. CHKDSK repairs and pending-action reversion have no simple undo; rely on the pre-repair image or backup. Re-enable clean-boot items from the recorded list after the responsible component is isolated.

• Windows completes three normal starts and one cold boot without 0xEF.
• Safe Mode and normal mode both remain usable.
• Event Viewer records no new 0xEF bug check.
• DISM and SFC report no unresolved corruption when used.
• Storage and memory tests remain clean if corruption was unexplained.
• The repaired state survives re-enabling required services and startup items.

Confidence is approximately 85–90% only when a specific update, driver, service, file, storage fault, or memory fault is demonstrated and reversing it stops the crashes. The generic decision tree is approximately 75–80% useful for reaching that diagnosis, but 0xEF alone does not justify one universal fix. Stop when evidence points to unstable hardware, no reproducible cause can be isolated, or repair-source matching becomes necessary.