How to Clean Boot Windows 11 and Isolate Software Conflicts

Microsoft defines a clean boot as starting Windows with only essential drivers and startup programs so background software conflicts affecting apps or games can be isolated. It differs from Safe Mode: a clean boot gives you more control over which non-Microsoft services and startup apps are removed from the test environment.

Use it when Windows can still start normally and a repeatable problem may depend on third-party background software—for example, an application that fails only with an overlay, utility, security product, peripheral suite, or other startup component present. If Windows cannot boot normally, use the Windows Recovery Environment path instead.

Sign in with an administrator account. Before disabling anything, record which startup apps are enabled and which non-Microsoft services are active. Microsoft explicitly tells users to keep track of disabled startup items because they need to be restored later. Screenshots are a simple way to preserve that state.

Do not use the Boot tab's advanced options as a performance tweak. Microsoft's clean-boot procedure uses the Services and Startup paths; its support guidance warns that changing advanced boot options in System Configuration can make a computer unusable.

Open Search, type msconfig, and open System Configuration. On the Services tab, select Hide all Microsoft services first, then select Disable all and Apply. Hiding Microsoft services before disabling the remainder is the important boundary in Microsoft's documented procedure.

Open the Startup tab and choose Open Task Manager. In Task Manager's Startup apps page, disable each currently enabled startup item while keeping a record of what you changed. Close Task Manager, select OK in System Configuration, and restart the PC. Windows will then start in the clean-boot environment.

After restart, repeat the same action that exposed the original problem. Use the same application, game, installer, device, file, or workload where practical. Avoid simultaneously updating drivers, reinstalling software, changing firmware settings, or applying registry tweaks; multiple changes destroy the value of the A/B test.

If the problem still occurs in the clean-boot environment, Microsoft says the issue is not caused by interference from a disabled service or startup app. That does not identify the root cause by itself; it simply moves the investigation away from the software removed by this test.

When the problem does not occur in a clean boot, the useful result is that something removed from normal startup is involved. Microsoft recommends systematically re-enabling services and startup items and restarting to find the cause. Testing roughly half of the remaining candidates at a time is more efficient than enabling one item per reboot when many candidates exist.

Keep the original symptom as the test condition after every restart. If the problem returns, the culprit is in the group you just enabled; if it remains absent, focus on the other disabled group. Continue narrowing until one service or startup application is associated with the failure. Correlation from this procedure is stronger evidence than guessing from a process name alone.

If your test involves installing or uninstalling software, Microsoft notes that Windows Installer might not start when system services are not loaded. If you receive the documented Windows Installer service error, open Computer Management, expand Services and Applications, open Services, and start Windows Installer before repeating the install or uninstall test.

Do this only when the clean-boot test actually requires installation activity. It is not necessary for an ordinary app-launch or gameplay conflict test.

Do not leave the PC in a clean-boot configuration after troubleshooting. Return to System Configuration and restore the normal service configuration, then re-enable the startup applications you recorded before the test. Restart and verify that expected background functionality has returned.

If you identified one conflicting third-party component, keep the broader Windows startup state normal and address that specific application or service through its supported update, configuration, uninstall, or vendor-support path. A clean boot is valuable because it narrows the failure domain; it is not itself the long-term fix.

A successful clean-boot comparison can establish that disabled background software participates in a reproducible problem. It cannot prove that Windows, a driver, or hardware is healthy in every other respect. Likewise, a problem that persists during clean boot does not automatically diagnose defective hardware.

The safest workflow is bounded: preserve the starting state, create the documented clean-boot environment, reproduce one known symptom, isolate disabled items only when the symptom disappears, restore normal startup, and then act on the specific evidence you found.