Recover from a CRITICAL_SERVICE_FAILED startup loop

Windows stops during startup with CRITICAL_SERVICE_FAILED. This bug check is rare. It indicates that a critical service or boot dependency did not initialize successfully, but the blue-screen name normally does not identify which service, driver, filter, update, or system file caused the failure.

Search CRITICAL_SERVICE_FAILED 0x5A together with the most recent driver, security product, cleanup operation, update KB, or service/driver name found in logs. 0x5A alone is not permission to disable services at random.

Use this procedure when Windows repeatedly stops with 0x5A and WinRE or Safe Mode can be reached.

Do not use it for CRITICAL_PROCESS_DIED, 0xc000021a, or an ordinary Service Control Manager error on an otherwise booting computer. Do not use it when the disk or memory is unstable.

The exact build may remain unknown for initial restore, update removal, Safe Mode testing, and offline SFC. The service or driver name may remain unknown during the first reversible steps, but it must be demonstrated before an offline registry disable is attempted.

Before you start:

Windows Recovery Environment or installation media
Command Prompt
Safe Mode when available
A restore point, update rollback option, dump, or service/driver evidence
A recorded rollback value before any offline service change

Open Repair your computer > Troubleshoot > Advanced options. Start with Startup Settings and reversible recovery options. Do not begin by disabling service groups.

Do not disable all Start=0 or Start=1 entries.
Do not disable core Microsoft storage, ACPI, file-system, Plug and Play, registry, or session services.
Do not permanently set nointegritychecks, testsigning, or disabled signature enforcement.
Do not delete driver files manually before preserving the package and rollback path.
Do not assume every Service Control Manager error is the cause; many are consequences of the failed boot.
Do not run BCD reconstruction without BCD evidence.

Stop before offline registry changes if the exact service is unknown, or if the candidate is a core Microsoft/storage component without a tested recovery path.

Check the cause

Record the complete blue-screen code and every preceding change, especially:
- driver or security-software installation;
- registry/service cleanup or optimization;
- Windows update;
- Driver Verifier activation;
- manual change to a service's Start value or dependency.
Select Startup Settings > Restart.
First try Safe Mode. If it starts, preserve relevant logs:
- System log entries from Service Control Manager;
- Reliability Monitor failures;
- the latest files in C:\Windows\Minidump or C:\Windows\MEMORY.DMP;
- exact recent driver and application versions.

If Safe Mode fails, return to WinRE Command Prompt and map Windows as W::

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

Confirm the installation and dump availability:

dir W:\Windows\System32\Config\SYSTEM
dir W:\Windows\Minidump
dir W:\Windows\MEMORY.DMP

If the screen names a specific file, driver, or signature error, follow that evidence. Use FIX-066 for a Microsoft file checksum failure.
As a one-boot diagnostic only, Disable driver signature enforcement from Startup Settings. If Windows starts only under that option, an unsigned, damaged, or policy-blocked driver is implicated. Do not make signature enforcement permanently disabled.
If no service or driver can be identified, use the reversible branches below. Do not proceed to offline registry editing.

Proceed from least invasive to most targeted.

Branch A — Restore the state before the failure

Select Advanced options > System Restore.
Choose a restore point from before the driver, service, security-product, or cleanup change.
Review affected programs and complete the restore.
Restart and test twice.

Branch B — Remove a directly preceding update

Select Advanced options > Uninstall Updates.
Choose Uninstall latest quality update when the first 0x5A followed a monthly update.
Choose the feature-update rollback option only when a version upgrade was the trigger and that option is available.
Restart and test.

Branch C — Remove a demonstrated third-party component in Safe Mode

In Safe Mode, record the component's publisher, version, driver name, and installation date.
For application-managed security, backup, filter, or hardware software, uninstall it through Settings > Apps > Installed apps rather than deleting its SYS file.
For a recently updated device driver, use Device Manager > device Properties > Driver > Roll Back Driver when available.
To inventory third-party driver packages, open an administrator Command Prompt and run:
```
pnputil /enum-drivers
```
Remove a driver package only when its published name and relationship to the failure are proven:
```
pnputil /delete-driver oem<number>.inf /uninstall
```
Restart normally. If the device needs a driver, install a known-compatible OEM/vendor package after Windows is stable.

Branch D — Repair protected Windows files

From WinRE, run offline SFC:

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

Record the final result and restart if repairs were made.
If SFC needs external repair content, use FIX-066's matching-source procedure.

Branch E — Disable one proven non-Microsoft service or driver offline

Use this only when logs, a dump, signature testing, or the immediately preceding installation identifies one exact non-Microsoft service/driver. Do not use this branch for storage, file-system, encryption, antivirus filter, or other boot-critical dependencies unless a tested rollback is ready and the causal evidence is strong.

Create the backup directory:
```
md W:\BootRepairBackup
```

Load the offline SYSTEM hive:

reg load HKLM\OfflineSystem W:\Windows\System32\Config\SYSTEM

Determine the active control set:
```
reg query HKLM\OfflineSystem\Select
```
Convert the Current value to the corresponding key. For example, Current = 0x1 means ControlSet001; 0x2 means ControlSet002.

Query the exact demonstrated service:

reg query HKLM\OfflineSystem\ControlSet00<number>\Services\<service-name>

Record its original Start, ImagePath, Type, and dependency values.

Export only that service key:

reg export HKLM\OfflineSystem\ControlSet00<number>\Services\<service-name> W:\BootRepairBackup\<service-name>-before-disable.reg

Disable that one proven third-party component:

reg add HKLM\OfflineSystem\ControlSet00<number>\Services\<service-name> /v Start /t REG_DWORD /d 4 /f

Unload the hive:
```
reg unload HKLM\OfflineSystem
```
Restart. If Windows starts, remove or replace the owning product correctly; do not leave an unknown orphaned driver indefinitely.

Check the result

Windows completes three normal starts with standard signature enforcement.
The implicated service or driver is removed, replaced, or intentionally disabled with its owner documented.
Event Viewer contains no repeated Service Control Manager failures for the critical dependency.
sfc /scannow reports no unresolved integrity violations.
Required devices and security functions still operate after the repair.
System Restore or update removal fixes startup: Record the reverted component and delay reinstallation until its compatibility is understood.
Safe Mode works and removal of one component fixes normal startup: Preserve its exact package and driver information.
Windows boots only with signature enforcement disabled: Identify and replace/remove the named driver; permanent integrity bypass is not the fix.
Offline SFC repairs files: Verify whether a service binary or dependency was restored.
Disabling one proven third-party service restores startup: Uninstall or update the owning software, then retest with normal integrity enforcement.
No component is identified: Stop. The correct next step is dump/log analysis, not bulk service disabling.

To undo the change:

For an offline service change, reload the SYSTEM hive under the same HKLM\OfflineSystem name and restore the recorded original Start value, or import the saved key while the hive is loaded. Then unload the hive and restart. A removed driver package should be reinstalled only from its verified OEM/vendor package. System Restore can usually be undone after Windows becomes accessible.

Type	Searchable identifier	When it applies
Blue-screen bug check	`0x0000005A` — `CRITICAL_SERVICE_FAILED`	Primary and defining code for this writeup.
Short stop display	`0x5A`	Equivalent shortened bug-check value.
Windows Recovery	`0xc0000428` — `STATUS_INVALID_IMAGE_HASH`	A boot-critical service or driver is blocked because Windows cannot verify its signature/hash. Use only when the screen names the file.
Windows bug check/status	`0xc0000221` — `STATUS_IMAGE_CHECKSUM_MISMATCH`	A named service binary, driver, or system file fails checksum. Use FIX-066 for the file-integrity repair.
Blue-screen bug check	`0x000000C4` — `DRIVER_VERIFIER_DETECTED_VIOLATION`	Driver Verifier identifies a driver. Use the Driver Verifier recovery condition rather than treating `0x5A` as the only evidence.
Blue-screen bug check	`0x0000007E` — `SYSTEM_THREAD_EXCEPTION_NOT_HANDLED`	A boot driver throws an unhandled exception. Apply it only when a dump names the same driver involved in the service failure.
Service Control Manager	`Event ID 7000`	A service failed to start. Record the service name and error text.
Service Control Manager	`Event ID 7001`	A service failed because a dependency did not start. Record both services.
Service Control Manager	`Event ID 7026`	A boot-start or system-start driver failed to load. Record every named driver.