Windows 11 Slow Boot Time After Update: Quick Fix
Short answer up front: Windows 11 boot time getting worse right after an update is almost always one of four things — a driver that's taking longer to initialize post-update, a startup app that got silently re-enabled, Fast Startup interacting badly with a changed driver, or pending update cleanup work still running in the background. You can identify which one you have in about five minutes using Event Viewer, and the fix is different for each, so don't start uninstalling drivers or resetting the PC before you check.
Confirm it with Event Viewer boot diagnostics
Windows logs every boot's duration automatically. Open Event Viewer, expand Applications and Services Logs > Microsoft > Windows > Diagnostics-Performance > Operational. Look for Event ID 100, labeled "Windows has started up" — it reports total boot duration in milliseconds and an IsDegradation flag. If that flag is true, or if you see follow-up events in the 101-110 range right after it, Windows itself has identified something specific slowing you down, not just a vague feeling that things got slower.
- Event ID 101 — an application took longer than expected to start. The event details name the exact app and how many extra milliseconds it added.
- Event ID 102 — a driver took longer than expected to initialize. Again, named directly in the event.
- Event ID 100 with no follow-up events — boot was slow but Windows didn't isolate a specific cause. Move to the manual checks below.
Create a filtered view so you're not scrolling through noise: right-click Diagnostics-Performance > Operational, choose Filter Current Log, and enter 100,101,102 in the Event IDs box. Sort by date and compare your boot times from before the update to now — this turns "it feels slower" into an actual number you can act on. Microsoft's own reference for what each event ID in this log means is documented at Event ID 100: Windows Diagnostics Performance, if you want the full breakdown of what counts as a degradation versus normal boot-to-boot variance.
The most common cause: a startup app got re-enabled
Cumulative and feature updates occasionally reset Task Manager's startup app list, silently re-enabling entries you'd previously turned off — this is a documented behavior pattern across Windows feature updates, not a one-off glitch. Check first, since it's the fastest fix if it applies:
- Press Ctrl+Shift+Esc to open Task Manager, then click the Startup apps tab.
- Sort by the Startup impact column, highest first.
- Right-click anything marked High or Medium that you don't need running the moment you log in — sync clients, chat apps, launcher software, printer utilities — and select Disable.
- Leave anything labeled with "Microsoft" as the publisher alone unless you specifically recognize and don't want it; these are usually core OS components, not bloat.
- Restart and compare your Event ID 100 boot duration to the previous entry.
This alone resolves a meaningful share of "got slow after update" cases in my experience, because people had already trimmed their startup list once, the update quietly undid part of it, and nobody thought to check Task Manager again.
If Event ID 102 names a driver
A driver initializing slowly after a Windows update usually means the update installed a newer in-box driver that doesn't play well with your specific hardware revision, or it left an older third-party driver trying to negotiate with a changed kernel interface. Open Device Manager, find the device named in the Event ID 102 details, right-click it, and check Driver tab > Roll Back Driver. If that option is grayed out (no previous driver stored), instead go to the manufacturer's own site — not Windows Update — and install their current driver directly; OEM drivers are frequently newer and better-tested against odd hardware combinations than whatever Windows Update pushes automatically. Storage controllers and network adapters are the two device classes I see flagged here most often, since both sit directly in the boot path.
Fast Startup: helpful normally, a problem after some updates
Fast Startup hibernates the kernel session on shutdown instead of fully closing it, which speeds up a normal boot — but if an update changed a driver that Fast Startup's saved session doesn't handle correctly, you can end up with the opposite effect: a boot that hangs waiting on stale driver state before recovering. It's a quick, fully reversible thing to rule out:
- Press Win+R, type
powercfg.cpl, press Enter. - Click "Choose what the power buttons do."
- Click "Change settings that are currently unavailable" (requires admin rights).
- Uncheck "Turn on fast startup (recommended)."
- Save changes, then do a full Restart (not Shut down) so the change actually takes effect on the next boot.
If boot time improves noticeably, you've confirmed Fast Startup was the friction point. You can leave it off permanently with only a small tradeoff — a cold boot from a complete shutdown, not a resume from hibernation — or re-enable it later once you've updated the driver that was likely the real conflict.
Ruling out leftover update cleanup work
Immediately after a large cumulative or feature update, Windows Update sometimes still has background component-store cleanup and servicing work queued for the first several boots — this genuinely does add real seconds to early startups and tapers off within a few reboots. Before assuming this is a permanent regression, restart the machine two or three times over a day and compare Event ID 100 durations across those boots rather than judging from a single instance right after the update landed. If duration is trending down boot over boot, this was transient. If it's flat or getting worse, treat it as one of the other causes above.
If you want to manually clear space and finished update leftovers rather than waiting it out, open Settings > System > Storage > Temporary files, and check Windows Update Cleanup and Delivery Optimization Files specifically — both can hold onto gigabytes after a big update and occasionally interact with slower disk operations during early boot on systems already tight on free space.
Symptom-to-fix quick reference
| Event Viewer shows | Fix |
|---|---|
| Event 100 with IsDegradation true, Event 101 naming a specific app | Disable that app in Task Manager's Startup apps tab |
| Event 100 with IsDegradation true, Event 102 naming a specific driver | Roll back the driver, or install the OEM's current version directly |
| Event 100 boot time improving each of the first several boots after update | Nothing needed — background servicing work tapering off |
| Event 100 slow, no 101/102 follow-up at all | Test with Fast Startup disabled, then a clean boot to isolate a service |
What I would not do
- Don't reset the PC or reinstall Windows before checking Event Viewer once. It's a five-minute check that frequently points straight at the cause.
- Don't disable every startup app indiscriminately, including your antivirus or backup client, just to see what happens. Disable the specific high-impact items you don't actually need at login.
- Don't leave Fast Startup off "just in case" without testing whether it was actually the cause — you're giving up a real convenience for no measured benefit if it wasn't.
If you've worked through Event Viewer, trimmed startup apps, ruled out a driver, and boot time still hasn't recovered after several clean restarts, run sfc /scannow followed by DISM /Online /Cleanup-Image /RestoreHealth from an elevated Command Prompt to rule out system file corruption from an interrupted update, then move on to checking whether this is actually the freezing-after-update problem wearing a different symptom — a system that's struggling on every boot sometimes turns out to be a broader post-update stability issue rather than a pure speed one.