Confirmed
- A process required for Windows to continue safely terminated or became corrupted.
- The bug-check value associated with this family is 0x000000EF.
BSOD · reviewed 2026-09-01
CRITICAL_PROCESS_DIED Stop Code diagnostic
A process required for Windows to continue safely terminated or became corrupted.
High for the Stop Code familyLow until dump parameters and recurrence context are reviewed
Real cases
Resume a saved session — paste a Resume Capsule
The capsule is validated and restored only in this browser. An invalid capsule changes nothing.
Crawlable evidence ledger
What this diagnostic record establishes
Not confirmed
- The Stop Code alone does not identify the exact driver, device, or hardware part responsible.
- A filename shown on screen or in a dump can be involved without being the original cause.
Context changes the route
When does the blue screen occur?
Startup
Likely layer: Critical system process, storage, system files, or driver path
First safe check: Check whether Windows produced time-matched crash evidence
Expected: A matching minidump and repeatable trigger provide stronger evidence than the Stop Code alone.
Sleep or wake
Likely layer: Critical system process, storage, system files, or driver path
First safe check: Check whether Windows produced time-matched crash evidence
Expected: A matching minidump and repeatable trigger provide stronger evidence than the Stop Code alone.
Gaming or heavy load
Likely layer: Critical system process, storage, system files, or driver path
First safe check: Check whether Windows produced time-matched crash evidence
Expected: A matching minidump and repeatable trigger provide stronger evidence than the Stop Code alone.
After an update or driver change
Likely layer: Critical system process, storage, system files, or driver path
First safe check: Check whether Windows produced time-matched crash evidence
Expected: A matching minidump and repeatable trigger provide stronger evidence than the Stop Code alone.
Random or idle
Likely layer: Critical system process, storage, system files, or driver path
First safe check: Check whether Windows produced time-matched crash evidence
Expected: A matching minidump and repeatable trigger provide stronger evidence than the Stop Code alone.
Before any second repair step
Verify the observation and preserve the evidence
After the first safe check, record whether the reviewed intermediate result occurred, whether the original problem was retested, and the exact output. An expected observation is not automatically a repair.
Outcome boundaries
- Observed as expected
- Observed something different
- Result unclear
- Could not complete the check
Then separately record whether the original problem still occurs, was not reproduced once, or has not been retested yet. Every session ends in stop, one repeat of the same check, one named missing fact, or escalation—never an open-ended repair sequence.
Evidence fields for this task
- Exact crash timeLocal date and time from the most recent crash
- Trigger or workloadStartup, sleep/wake, game, update, idle, or unknown
- Recurrence patternOnce, count, frequency, and whether the Stop Code repeats
- Minidump statusExists/missing and the time shown; do not upload it here
The browser-local Evidence Pack combines the selected context, safe action, actual observation, sources, review date, missing evidence, and stop boundary. It can be copied or printed without creating an account or uploading a log.
After you perform the safe check
Read the evidence you collected
Paste a bounded msinfo32 or DxDiag text report and extract the Windows build, system model, firmware mode, memory, DirectX, display-driver, and explicitly reported problem-device facts without uploading the report.
Review trail
Official and first-party sources
- Bug Check Code Reference Microsoft Learn · primary
- Stop code error or bug check troubleshooting Microsoft Learn · primary
- Read small memory dump files Microsoft Learn · primary