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.

Searchable Windows error codes and exact messages

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.

• 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.

1. 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.

2. Select Startup Settings > Restart.

3. 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.

4. 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
   

5. Confirm the installation and dump availability:

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

6. If the screen names a specific file, driver, or signature error, follow that evidence. Use FIX-018 for a Microsoft file checksum failure.

7. 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.

8. 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

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

Branch B — Remove a directly preceding update

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

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

1. In Safe Mode, record the component's publisher, version, driver name, and installation date.

2. For application-managed security, backup, filter, or hardware software, uninstall it through Settings > Apps > Installed apps rather than deleting its SYS file.

3. For a recently updated device driver, use Device Manager > device Properties > Driver > Roll Back Driver when available.

4. To inventory third-party driver packages, open an administrator Command Prompt and run:

   pnputil /enum-drivers
   

5. Remove a driver package only when its published name and relationship to the failure are proven:

   pnputil /delete-driver oem<number>.inf /uninstall
   

6. 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

1. From WinRE, run offline SFC:

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

2. Record the final result and restart if repairs were made.

3. If SFC needs external repair content, use FIX-018'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.

1. Create the backup directory:

   md W:\BootRepairBackup
   

2. Load the offline SYSTEM hive:

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

3. Determine the active control set:

   reg query HKLM\OfflineSystem\Select
   

4. Convert the Current value to the corresponding key. For example, Current = 0x1 means ControlSet001; 0x2 means ControlSet002.

5. Query the exact demonstrated service:

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

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

7. Export only that service key:

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

8. Disable that one proven third-party component:

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

9. Unload the hive:

   reg unload HKLM\OfflineSystem
   

10. Restart. If Windows starts, remove or replace the owning product correctly; do not leave an unknown orphaned driver indefinitely.

• 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.

• 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.

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.

• 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.

Confidence is approximately 85–90% when a dump, log, signature test, or immediate preceding change identifies one component and reversing it restores startup. Confidence is below 70% when only 0x5A is known. 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.