How to Fix Windows Update Not Working in Windows 11

Introduction

Windows Update is one of the most important background services in Windows 11. It delivers security patches, driver updates, feature improvements, and stability fixes that keep your system protected and running smoothly. When it stops working, you may see error codes such as 0x80070002, 0x800f0922, or 0x80248007, or the Settings app may simply hang on “Checking for updates” indefinitely. For beginners, this can feel like a dead end. For IT administrators managing fleets of devices, it can disrupt patch compliance and expose endpoints to known vulnerabilities.

This guide covers How to Fix Windows Update Not Working in Windows 11 in practical, step-by-step detail. It focuses on the most common causes: corrupted update components, damaged system files, misconfigured services, blocked network ports, and leftover update caches. The procedures here rely on built-in Windows tools such as the Windows Update Troubleshooter, Deployment Image Servicing and Management (DISM), System File Checker (SFC), and the Background Intelligent Transfer Service (BITS). No third-party repair suites are required, although you may use them if your organization’s policy allows it.

Before you begin, keep one key fact in mind: keeping your operating system updated before installation prevents dependency conflicts. If you are applying a repair on a device that has skipped several cumulative updates, install the latest servicing stack update (SSU) first. Also, always verify software compatibility with your hardware architecture (ARM64 vs x86). Commands and package paths differ between these architectures, and running the wrong binary or script can leave the update stack in a worse state than before.

This article is written for two audiences. Beginners can follow the steps in order and stop when the problem is resolved. IT administrators can use the same steps as a structured runbook, applying them through Group Policy, Intune, or PowerShell remoting across multiple machines. The total time to complete the full procedure is typically 30 to 90 minutes, depending on disk speed, network conditions, and how many components must be repaired.

Prerequisites

Gather the following before you start. Missing prerequisites are a common reason repairs fail partway through.

• Administrative credentials on the Windows 11 device. Most repair commands require an elevated Command Prompt or PowerShell session.
• A stable internet connection. Windows Update needs to reach Microsoft Update servers on HTTPS (TCP 443) and BITS uses TCP 80 and 443.
• At least 15 to 20 GB of free disk space on the system drive, since update components and temporary files can grow during repair.
• A recent backup or restore point for business-critical systems. IT administrators should ensure the device is enrolled in a management platform so you can reimage if required.
• Knowledge of the device architecture. Run echo %PROCESSOR_ARCHITECTURE% or check Settings > System > About. ARM64 devices use different driver packages and offline update files than x86 or AMD64 devices.
• Access to Microsoft Update Catalog for manual .msu package downloads if automatic discovery fails.
• Optional but recommended for administrators: WSUS or Windows Update for Business configuration documentation, so you can confirm whether the device is pointed at an internal update server.

Preparation

Preparation reduces the chance that a failed step leaves the system in an inconsistent state. Work through these items before running any repair command.

First, confirm the current update state. Open Settings > Windows Update and note the last successful update date and any error code shown. Record the OS build number from winver. If the build is significantly behind the current servicing baseline, install the latest servicing stack update manually from the Microsoft Update Catalog. Keeping the OS updated before installation prevents dependency conflicts, and this is especially true for the servicing stack, which orchestrates every subsequent update.

Second, verify architecture compatibility. On an ARM64 Surface device, for example, you must download ARM64 update packages and avoid running x86-only repair utilities under emulation. Mismatched architecture is a frequent cause of “not applicable” errors when applying offline packages.

Third, create a restore point. In an elevated Command Prompt, run systempropertiesprotection and create a restore point named “Pre-Update-Repair.” Administrators deploying across a fleet should verify that System Restore or a snapshot-based backup is enabled through policy.

Fourth, disable third-party antivirus temporarily if it is known to interfere with BITS. Re-enable it after the repair is complete, or configure exclusions for the SoftwareDistribution folder.

Fifth, close all applications and save your work. Some repair steps restart services and can interrupt file operations.

Finally, if the device is domain-joined, confirm that Group Policy is not blocking access to Windows Update. Run gpresult /h gpreport.html and review the Windows Update settings. Administrators should also check whether the device is dual-scanned by WSUS and Microsoft Update, which can cause conflicting update states.

Installation Steps

Step 1: Review prerequisites and compatibility

Confirm the device meets the baseline requirements described above. Verify Windows 11 build number, processor architecture, free disk space, and network access to Microsoft Update. Run these commands in an elevated PowerShell window to record the current state:

• Get-ComputerInfo | Select WindowsProductName, WindowsVersion, OsHardwareAbstractionLayer
• Get-Service wuauserv, bits, cryptsvc, msiserver | Select Name, Status, StartType
• Get-WindowsUpdateLog to generate a readable log at %USERPROFILE%\Desktop\WindowsUpdate.log if needed

If any required service is missing or disabled, note it. You will correct that in Step 3. If the architecture is ARM64 and you plan to apply an offline package, download the ARM64 build only.

Step 2: Prepare the environment

Stop the update-related services before clearing caches. Run the following in an elevated Command Prompt:

• net stop wuauserv
• net stop bits
• net stop cryptsvc
• net stop msiserver

Next, rename the SoftwareDistribution and Catroot2 folders so Windows rebuilds them cleanly. These folders hold downloaded update files and cryptographic catalog data. Do not delete them; rename them so you can restore them if needed.

• ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
• ren C:\Windows\System32\catroot2 Catroot2.old

Then reset the BITS queue and Winsock stack, which resolves many network-related update failures:

• netsh winsock reset
• netsh winhttp reset proxy
• bitsadmin /reset /allusers

If the device uses a proxy, confirm the proxy settings are correct before moving on.

Step 3: Configure core settings

Ensure the required services are set to their correct startup types and are running. Use services.msc or these commands:

• sc config wuauserv start= demand
• sc config bits start= delayed-auto
• sc config cryptsvc start= auto
• sc config msiserver start= demand

Start the services again:

• net start cryptsvc
• net start bits
• net start wuauserv
• net start msiserver

Register the core update DLLs to repair broken registrations. This is especially useful when the Settings app shows an error immediately on opening the update page:

• regsvr32 /s atl.dll
• regsvr32 /s urlmon.dll
• regsvr32 /s mshtml.dll
• regsvr32 /s shdocvw.dll
• regsvr32 /s browseui.dll
• regsvr32 /s jscript.dll
• regsvr32 /s vbscript.dll
• regsvr32 /s scrrun.dll
• regsvr32 /s msxml.dll
• regsvr32 /s msxml3.dll
• regsvr32 /s msxml6.dll
• regsvr32 /s actxprxy.dll
• regsvr32 /s softpub.dll
• regsvr32 /s wintrust.dll
• regsvr32 /s dssenh.dll
• regsvr32 /s rsaenh.dll
• regsvr32 /s gpkcsp.dll
• regsvr32 /s sccbase.dll
• regsvr32 /s slbcsp.dll
• regsvr32 /s cryptdlg.dll
• regsvr32 /s oleaut32.dll
• regsvr32 /s ole32.dll
• regsvr32 /s shell32.dll
• regsvr32 /s initpki.dll
• regsvr32 /s wuapi.dll
• regsvr32 /s wuaueng.dll
• regsvr32 /s wuaueng1.dll
• regsvr32 /s wucltui.dll
• regsvr32 /s wups.dll
• regsvr32 /s wups2.dll
• regsvr32 /s wuweb.dll
• regsvr32 /s qmgr.dll
• regsvr32 /s qmgrprxy.dll
• regsvr32 /s wucltux.dll
• regsvr32 /s muweb.dll
• regsvr32 /s wuwebv.dll

Administrators can wrap this list in a PowerShell loop to run it consistently across many endpoints.

Step 4: Run the main installation procedure

With services configured and caches cleared, run the system repair commands. Start with DISM to repair the component store, then run SFC to repair protected system files. Order matters: repairing the component store first gives SFC a reliable source for file replacement.

• DISM /Online /Cleanup-Image /CheckHealth
• DISM /Online /Cleanup-Image /ScanHealth
• DISM /Online /Cleanup-Image /RestoreHealth
• sfc /scannow

Allow the DISM RestoreHealth step to complete; it can take 15 to 30 minutes on slower disks. If the component store is severely damaged, you may need to specify a source with /Source:wim:<path>:1 /LimitAccess using an ISO that matches your build and architecture. This is where ARM64 versus x86 compatibility matters most: an image from the wrong architecture will fail immediately.

After SFC completes, restart the device. Then open Settings > Windows Update and select Check for updates. If updates still fail, use the Windows Update Troubleshooter from Settings > System > Troubleshoot > Other troubleshooters > Windows Update. The troubleshooter resets some components automatically and reports what it changed.

For persistent failures, reset Windows Update components using the script approach: stop services, rename SoftwareDistribution and Catroot2 again, re-register DLLs, and restart services. Reboot once more and retry the update.

Step 5: Verify the installation

Verification confirms the repair worked and that the device can receive future updates. Check the following:

• Windows Update history shows the latest cumulative update installed successfully with today’s date.
• Settings > Windows Update displays a green “You’re up to date” message.
• Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 lists recent patches.
• DISM /Online /Cleanup-Image /ScanHealth reports “No component store corruption detected.”
• Event Viewer > Applications and Services Logs > Microsoft > Windows > WindowsUpdateClient shows successful detection and download events with no new errors.

If updates install but fail on restart, check for pending reboots and ensure the device is not in a “pending update” state that blocks new scans.

Step 6: Configure post-install options

Set the device up to stay healthy. Configure active hours so updates do not restart the machine during work hours. Enable delivery optimization if your network has many devices, so they share update content locally. For administrators, consider setting deadlines for quality updates and deferring feature updates through Group Policy or Intune. Confirm that the device can reach both Microsoft Update and any WSUS server, and document the changes you made so the next technician can follow the same path.

Re-enable any antivirus or firewall components you disabled during preparation, and add exclusions for the SoftwareDistribution folder if interference recurs.

Post-Installation

After the repair is complete, run a full update cycle to confirm stability. Restart, check for updates again, and install any optional driver or firmware updates offered. On ARM64 devices, confirm that firmware updates from the OEM are installed through the appropriate channel, since some vendors deliver.