Stop a CRITICAL_PROCESS_DIED startup loop caused by a proven OEM service or recovery component

Windows repeatedly stops during startup with CRITICAL_PROCESS_DIED, and crash-dump plus service/package evidence identifies one exact OEM service, recovery agent, support utility, or its associated component as the cause. This is the narrow, evidence-based branch of the generic 0xEF procedure. The repair is to preserve the evidence, map the implicated process or module to its signed package and service, then update, uninstall, or temporarily disable only that component.

CRITICAL_PROCESS_DIED does not name the responsible product by itself. A dump can show the critical process that terminated, the process or thread context, and relevant modules, but ntoskrnl.exe, a vendor module on a stack, or one Service Control Manager event alone is not sufficient proof. Microsoft recommends comparing multiple dumps for consistent characteristics.

Searchable Windows error codes and exact messages

Search CRITICAL_PROCESS_DIED 0xEF together with the exact OEM product, service short name, executable or module path, file version, and computer model. Do not search only the blue-screen label and accept a generic service-disable list.

Use this procedure only when Windows repeatedly displays 0xEF and the OEM component is demonstrated by at least two independent links, such as:

• multiple dumps identify the same OEM process, module, or failure context;
• the binary path, signature, and version map to one installed OEM package and service;
• Safe Mode starts while normal startup crashes when that component loads;
• an OEM advisory identifies the exact product/version; or
• disabling, removing, or updating only that component stops the reproducible crash.

The last result is the strongest confirmation, but it should be attempted only after the service identity and a rollback path are preserved.

Do not use this article for an undiagnosed CRITICAL_PROCESS_DIED loop, a dump that shows only ntoskrnl.exe, an arbitrary OEM utility installed on the machine, or a single vendor module merely present on the stack. Do not use it when storage, memory, file-system, in-page, checksum, or servicing evidence is stronger; when the displayed code is 0xc000021a, 0x7A, 0x24, or 0xF4; or when a .sys boot driver/filter is the demonstrated cause. Use the generic 0xEF, boot-driver, storage, memory, or servicing procedure instead.

Do not disable an OEM security, authentication, encryption, firmware-management, thermal, fan, or platform service unless its exact role, ownership, recovery path, and effect on startup have been established.

The source-code defect inside the OEM component, exact Windows build during the initial evidence-preservation phase, and why Windows marked or lost the critical process may remain unknown. The exact build becomes necessary when choosing a compatible replacement package.

The service short name, executable path, signer/publisher, package name and version, original start type, dump location, and evidence connecting the component to 0xEF may not remain unknown before disablement or removal. A display name alone is insufficient because it can differ from the service short name used by sc.exe and the registry.

• Windows Recovery Environment and Startup Settings
• Safe Mode if it remains bootable
• A USB or other destination for crash dumps, event logs, service configuration, and registry-hive backups
• WinDbg on a working Windows computer, with Microsoft symbols available
• Administrator access for service inspection, update, removal, or temporary disablement
• The exact OEM support package or uninstaller for the exact model and Windows version when available
• A restore point, system image, or documented method to restore the component and its original service start type

Do not proceed from a search-result claim alone. Preserve at least one dump, and preferably two or more crashes with matching characteristics, before removing the package.

Open Windows Recovery Environment > Troubleshoot > Advanced options > Startup Settings > Restart. First choose Disable automatic restart after failure if the blue screen disappears too quickly, record the complete 0xEF display, then return and try Safe Mode.

If Safe Mode starts, do not run disk cleanup, an OEM cleanup tool, or an automated reset. Copy the dumps and export the evidence before changing the service. If Safe Mode also crashes, use WinRE Command Prompt and detect the offline Windows and USB volumes; never assume Windows is C:.

The purpose of the first pass is attribution, not repair. Do not disable any service until its short name, binary path, signer, version, package owner, original start configuration, and rollback method are recorded.

1. Record the blue-screen label and any bug-check parameters in Event Viewer after a successful Safe Mode start. In Event Viewer > Windows Logs > System, locate event 1001 from WER-SystemErrorReporting at the crash time, whose message begins The computer has rebooted from a bugcheck, and export it.

2. Preserve available dumps and logs from Safe Mode:

   md U:\CriticalProcessEvidence
   echo %SystemRoot%
   copy "%SystemRoot%\Minidump\*.dmp" U:\CriticalProcessEvidence
   copy "%SystemRoot%\MEMORY.DMP" U:\CriticalProcessEvidence
   wevtutil epl System U:\CriticalProcessEvidence\System.evtx /ow:true
   wevtutil epl Application U:\CriticalProcessEvidence\Application.evtx /ow:true
   

   Replace U: with the detected evidence-drive letter. A missing minidump or MEMORY.DMP produces a copy error; record it rather than claiming the file exists.

3. If Safe Mode does not start, detect and map the offline Windows volume from WinRE:

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

   Use assign only when the verified Windows volume has no letter and list volume proves that W: is unused; record W: as temporary. If the volume already has a letter, keep it and substitute that letter below. Verify the already identified installation and then copy evidence:

   dir W:\Windows\System32\Config\SYSTEM
   md U:\CriticalProcessEvidence
   copy W:\Windows\Minidump\*.dmp U:\CriticalProcessEvidence
   copy W:\Windows\MEMORY.DMP U:\CriticalProcessEvidence
   copy W:\Windows\System32\winevt\Logs\System.evtx U:\CriticalProcessEvidence
   copy W:\Windows\System32\winevt\Logs\Application.evtx U:\CriticalProcessEvidence
   

4. Open each preserved dump in WinDbg on a working computer. Set Microsoft symbols, reload, and run the standard analysis:

   .symfix
   .reload
   !analyze -v
   

5. Record the bug-check value, all four parameters, PROCESS_NAME, exception or termination status when shown, stack, image/module names, and failure bucket. Do not treat Probably caused by as a complete diagnosis without checking the process and module ownership.

6. For 0xEF with parameter 2 equal to 0, inspect the process object address from parameter 1:

   !process <parameter-1-address> 1f
   

   For parameter 2 equal to 1, inspect it as a thread object and then identify the owning process:

   !thread <parameter-1-address>
   

7. When a specific non-Microsoft module is relevant, inspect its path, timestamp, version, and publisher information:

   lmvm <module-name-without-extension>
   

8. Compare at least two dumps when available. Strong evidence repeats the same terminated process, OEM module, service interaction, exception, or failure bucket. If the implicated process/module changes or storage/in-page statuses appear, stop and reclassify.

9. In Safe Mode, map the service short name to its configuration. Replace the placeholder only with the proven service:

   sc.exe qc "<service-short-name>"
   sc.exe queryex "<service-short-name>"
   sc.exe qfailure "<service-short-name>"
   sc.exe enumdepend "<service-short-name>"
   reg query "HKLM\SYSTEM\CurrentControlSet\Services\<service-short-name>" /v DelayedAutoStart
   

   Save TYPE, BINARY_PATH_NAME, START_TYPE, ERROR_CONTROL, account, dependencies, reverse dependents, current state/PID, and recovery actions. Continue only for an optional Win32 OEM service. Stop if TYPE is a kernel or file-system driver, START_TYPE is boot or system start, ERROR_CONTROL is severe or critical, or enumdepend names an essential service. If qfailure shows Restart the Computer, distinguish that configured restart from the actual 0xEF event; the service event and bug-check event must still align.

10. Inspect the service registry entry without changing it:

    reg query "HKLM\SYSTEM\CurrentControlSet\Services\<service-short-name>" /s
    

11. Extract the actual executable path from BINARY_PATH_NAME, excluding arguments, then verify its signer and version in an administrator PowerShell window:

    Get-AuthenticodeSignature -FilePath "<full-executable-path>" | Format-List Status,StatusMessage,SignerCertificate
    (Get-Item "<full-executable-path>").VersionInfo | Format-List CompanyName,ProductName,FileVersion,ProductVersion,OriginalFilename
    

12. Confirm that the signed binary and version belong to the installed OEM application or recovery package through Windows 11 Settings > Apps > Installed apps, Windows 10 Settings > Apps > Apps & features, or Control Panel > Programs > Programs and Features. Record its exact version and install date. If the path is under Windows\System32, is Microsoft-signed, is a shared svchost.exe group, or cannot be tied to the OEM package, stop before disabling it.

13. Check Reliability Monitor, the Application log, and Service Control Manager events for the same component immediately before each 1001 bug-check event. Time correlation supports the dump; it does not replace it.

14. Choose the least invasive proven branch:

    • an OEM correction for the exact model/package exists: Branch A;
    • the package is optional and its supported uninstaller works in Safe Mode: Branch B;
    • a reversible service A/B test is required: Branch C;
    • neither Safe Mode nor the uninstaller starts, but service attribution is strong: Branch D;
    • a restore point predates the component update and attribution is not sufficient for offline editing: Branch E.

Branch A — Install the OEM's corrected component version

1. Confirm that the OEM package names the exact computer model, Windows 10/11 version and architecture, affected component, and corrected version.

2. Preserve the current installer, version, dump analysis, and service configuration. Create a restore point or image if Safe Mode permits it.

3. If the OEM installer explicitly supports Safe Mode, follow its documented update path. If it requires normal mode, use Branch C to disable only the proven service temporarily, start normal Windows, and then run the OEM installer.

4. Use the OEM-supplied installer or updater. Do not replace its executable or DLL manually and do not install a package for a similar model.

5. After installation, re-query the service and binary version. Restore the service's documented normal start type if the installer did not do so.

6. Restart normally and complete the verification in section 12. If the same 0xEF and evidence return, roll back the package and stop for the OEM; do not cycle through unrelated versions.

Branch B — Uninstall the exact optional OEM package from Safe Mode

1. Confirm from the OEM documentation that the component is optional or that its loss only removes a documented recovery, support, telemetry, or convenience feature.

2. Record any OEM recovery media or alternative Windows recovery method needed while the package is absent.

3. Select the exact recorded package through Windows 11 Settings > Apps > Installed apps, Windows 10 Settings > Apps > Apps & features, or Control Panel > Programs > Programs and Features, and use its supported uninstall option.

4. If the package supplies multiple services or drivers, allow its own uninstaller to remove them. Do not delete its directory, executable, DLL, .sys file, or service key manually.

5. Restart normally. If Windows starts, preserve the before/after service list and do not reinstall the same affected version.

6. Install only a corrected OEM version validated for the exact model and Windows build, or leave the optional component removed while its recovery/convenience function is documented as unavailable.

Branch C — Temporarily disable one proven OEM service for an A/B test

1. Save the complete output of sc.exe qc, sc.exe queryex, sc.exe qfailure, and sc.exe enumdepend. The original type, start mode—including delayed automatic state—error control, dependencies, reverse dependents, account, and recovery actions are the rollback record.

2. Confirm one final time that the short name maps to the signed OEM binary and not to a Microsoft service, shared host, hardware safety function, authentication component, encryption component, or required storage/network driver. Require an optional Win32 service, no essential reverse dependent, a non-boot/non-system start mode, and non-severe/non-critical error control.

3. Do not stop the service live as a routine test. A live stop can invoke a configured Restart the Computer recovery action or terminate a process Windows treats as critical. Stop it live only if the OEM explicitly documents that exact service as stop-safe and the recorded recovery actions contain no computer restart; otherwise leave the running instance alone and change only its next start.

4. Disable only its next start. The space after start= is required by sc.exe syntax:

   sc.exe config "<service-short-name>" start= disabled
   sc.exe qc "<service-short-name>"
   

5. Confirm that START_TYPE now reports disabled, then restart normally.

6. If Windows starts without 0xEF, preserve the service-disabled state only long enough to update or uninstall the owning OEM package. The A/B result strongly supports attribution but does not make permanent loss of the OEM function risk-free.

7. If the same crash continues, restore the original start type from section 11 and reclassify; do not disable another service without new evidence.

Branch D — Disable the exact service offline only when Safe Mode cannot start

Use this branch only when multiple dumps or an OEM advisory establish the service, its short name and path are verified, a SYSTEM-hive backup has a tested destination, and lack of essential reverse dependents was already established in Safe Mode or exact OEM documentation. If Safe Mode never ran and reverse dependencies cannot be verified, use System Restore or OEM recovery instead of experimenting in the offline registry.

1. From WinRE, detect the Windows and USB volumes as in section 7. Copy the offline SYSTEM hive before loading it:

   copy W:\Windows\System32\Config\SYSTEM U:\CriticalProcessEvidence\SYSTEM-before-OEM-service-disable
   

2. Load the offline hive under a temporary name and query both control-set selectors:

   reg load HKLM\OfflineSystem W:\Windows\System32\Config\SYSTEM
   reg query HKLM\OfflineSystem\Select /v Current
   reg query HKLM\OfflineSystem\Select /v Default
   

   From the moment reg load succeeds, every failure or stop path must unload the hive before leaving Command Prompt or rebooting:

   reg unload HKLM\OfflineSystem
   reg query HKLM\OfflineSystem
   

   The unload must report success, and the verification query must report that the key cannot be found. If unload fails, remain in WinRE, close any Registry Editor or process holding the hive, retry the unload, and do not reboot until it is verified absent. This catch-all applies if the selector values differ or any later save, query, path validation, edit, or verification fails.

3. Stop if Current and Default differ; this bounded procedure will not guess which divergent state should boot. Use the Default value for the next normal boot: 0x1 means ControlSet001, 0x2 means ControlSet002, and so on. Do not assume ControlSet001.

4. Before editing, make a second consolidated backup from the loaded hive and require the command to succeed:

   reg save HKLM\OfflineSystem U:\CriticalProcessEvidence\SYSTEM-before-OEM-service-disable.hiv /y
   dir U:\CriticalProcessEvidence\SYSTEM-before-OEM-service-disable.hiv
   

5. Query the exact service in the Default control set and preserve its original Start and ImagePath values:

   reg query "HKLM\OfflineSystem\ControlSet00<n-from-Default>\Services\<service-short-name>" /v Start
   reg query "HKLM\OfflineSystem\ControlSet00<n-from-Default>\Services\<service-short-name>" /v ImagePath
   

6. Continue only if ImagePath exactly matches the already verified OEM component and the original Start value is recorded. Set Start to 4, which means disabled, then verify the same key:

   reg add "HKLM\OfflineSystem\ControlSet00<n-from-Default>\Services\<service-short-name>" /v Start /t REG_DWORD /d 4 /f
   reg query "HKLM\OfflineSystem\ControlSet00<n-from-Default>\Services\<service-short-name>" /v Start
   

7. Unload the hive before restarting:

   reg unload HKLM\OfflineSystem
   reg query HKLM\OfflineSystem
   

   Require the unload to report success and the query to report that the key cannot be found. If unload fails, close Registry Editor and any process holding the hive, then retry. Do not restart while the hive remains loaded.

8. If—and only if—you assigned W: temporarily in section 7, remove it after the hive unload succeeds. Reidentify the same volume by number and details first; never remove a pre-existing Windows letter:

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

9. Start Windows normally. If startup succeeds, immediately preserve event logs, update or uninstall the owning OEM package, and keep the hive backup until verification is complete.

10. If startup still fails with the same evidence, restore the original Start value using section 11 and stop. Do not disable a second service speculatively.

Branch E — Use System Restore when a component update is the proven trigger but offline disablement is not safe

1. In WinRE, select Troubleshoot > Advanced options > System Restore.

2. Choose a restore point created before the exact OEM package update or installation.

3. Review affected applications and drivers. Do not proceed if the restore point would remove unrelated critical changes that cannot be recovered.

4. Complete the restore and test normal startup.

5. If Windows starts, record the restored package version and prevent only the known-bad OEM component version from reinstalling until a corrected package exists.

6. If 0xEF remains, preserve the new dump and compare it with the old ones; do not keep applying restore points without a changed result.

• A corrected OEM version stops the crashes: Keep the fixed version and preserve its exact package/model/build compatibility.
• Uninstalling the exact optional package stops the loop: The mechanism is strongly supported; document which OEM recovery/support function is no longer available.
• Disabling one verified service stops 0xEF: Treat it as a successful A/B isolation, then update or remove its owning package rather than leaving an unexplained permanent registry edit.
• The service is disabled but the identical crash continues: Restore its start type. The component was not the sole cause, or the actual cause is its driver/filter or another mechanism.
• The dump names a .sys driver or filter from the package: Stop this service-only path and use the proven boot-driver/filter procedure; do not delete the file manually.
• The dump shows 0xc0000006, disk I/O errors, changing damaged files, or different implicated processes: Storage or memory stability takes priority.
• Only a configured service restart occurs and there is no 0xEF/Event 1001: This is a service recovery-action problem, not CRITICAL_PROCESS_DIED.
• A Microsoft critical process is shown but no OEM module or service interaction is demonstrated: Return to the generic 0xEF procedure.

• Do not disable random OEM or non-Microsoft services until the crash stops.
• Do not disable smss.exe, csrss.exe, wininit.exe, services.exe, winlogon.exe, lsass.exe, logonui.exe, conhost.exe, or a Microsoft service because it appears as the terminated process.
• Do not treat ntoskrnl.exe, svchost.exe, or Probably caused by alone as proof of ownership.
• Do not use sc.exe delete, delete a service registry key, or manually remove an executable, DLL, or .sys file.
• Do not edit every ControlSet00x; use the offline Select\Default value for the next boot, require it to agree with Select\Current in this bounded procedure, and preserve the original start value.
• Do not restart while the offline SYSTEM hive remains loaded.
• Do not run Driver Verifier in an existing boot loop merely to produce another crash.
• Do not update BIOS, storage firmware, every driver, and the OEM component in one untraceable attempt.
• Do not reinstall the same affected OEM version immediately after its removal fixed startup.
• Do not reset or reinstall Windows before copying dumps, event logs, package versions, and service configuration.

For an online service change, use the exact original START_TYPE and DelayedAutoStart state recorded before the test. For an ordinary automatic-start service:

sc.exe config "<service-short-name>" start= auto

Replace auto only with the recorded original type, such as demand; do not guess. If the recorded state was delayed automatic, restore it specifically:

sc.exe config "<service-short-name>" start= delayed-auto
sc.exe qc "<service-short-name>"
reg query "HKLM\SYSTEM\CurrentControlSet\Services\<service-short-name>" /v DelayedAutoStart

Require the final configuration to match the record. A generic start= auto is not an exact restoration of delayed automatic start.

For an offline change, load the same SYSTEM hive, query both Select\Current and Select\Default, require them to agree, use the Default control set, and restore the original numeric Start value recorded before the edit (2 automatic, 3 manual, or the actual prior value). Verify the write, unload the hive successfully, and remove only a drive letter that this procedure assigned temporarily. Do not restore another machine's SYSTEM hive.

Reinstall or repair the component only with the exact compatible OEM package. Use System Restore's undo option when available if a restore introduced a new problem. If uninstalling the recovery component removed an OEM factory-recovery feature, keep verified Windows recovery media available until a fixed OEM package is installed and tested.

• Windows completes three normal starts and one cold boot without 0xEF.
• Event Viewer records no new BugCheck event 1001 for 0xEF and no matching unexpected-termination event for the OEM service.
• The corrected or removed package version and the service's intended final state are recorded.
• If the service is restored, it starts normally and its OEM function works without a crash.
• If the service remains disabled or the package remains removed, the documented security, thermal, input, update, and recovery functions required on that model still work or have an explicit alternative.
• New dumps do not repeat the same OEM process/module/failure bucket.
• Storage and memory evidence remains clean when the initial dump contained no I/O or corruption indicators.
• The result survives installation of the OEM-approved corrected version, if one is available.

Confidence is approximately 85–90% when multiple dumps repeat the same OEM context, the service maps to a signed and versioned package, and disabling, removing, or updating only that component stops the crashes through repeated cold starts. Confidence is approximately 75–80% when two strong evidence links exist but only one usable dump is available. 0xEF plus an OEM utility's mere presence is low-confidence and does not authorize service changes.

Stop when the service short name or binary ownership is uncertain, the path is Microsoft-owned or shared, the OEM component controls authentication, encryption, firmware, storage, thermal safety, or another essential platform function without a supported alternative, dumps disagree, in-page/storage/memory evidence appears, no rollback exists, or the offline hive cannot be backed up and unloaded cleanly. Escalate with the preserved dumps, service configuration, package version, model, and A/B result rather than disabling additional components.