Windows Update stuck or WSUS not working — full fix guide

Windows Update has two failure modes: client-side failures where a machine is stuck scanning or installing, and server-side failures where WSUS itself stops functioning. Both look like "updates aren't working" from the helpdesk queue, but the fixes are completely different. This runbook covers both paths — client stuck at 0%, WSUS console hanging, and the WSUS database bloat that eventually kills every unmanaged deployment.

Client-side: Windows Update stuck at 0% or scanning forever

The most common client-side failure pattern is the update scan hanging indefinitely. The Windows Update service is running but progress never moves. This is almost always a corrupted Software Distribution folder or a stuck Windows Update service.

Step 1 — Reset Windows Update components

:: Run as Administrator in an elevated CMD

:: Stop all update-related services
net stop wuauserv
net stop cryptSvc
net stop bits
net stop msiserver

:: Rename the corrupted cache folders
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old

:: Restart services
net start wuauserv
net start cryptSvc
net start bits
net start msiserver

After restarting the services, trigger a manual check: Settings > Windows Update > Check for updates. The scan will take longer than usual the first time because Windows is rebuilding the download cache from scratch.

Step 2 — Run the built-in DISM and SFC repair

A corrupted system image will cause update failures that survive the service reset. Run these in order:

:: Check and repair the Windows component store
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth

:: Then run System File Checker
sfc /scannow

Step 3 — Check the WindowsUpdate.log

:: Generate the readable log (PowerShell — required on Windows 10/Server 2016+)
Get-WindowsUpdateLog

:: The output goes to Desktop\WindowsUpdate.log
:: Search for "FATAL" or "WARNING" near the scan timestamp

Common log entries to look for:

Log entry	Meaning	Fix
0x80070005	Access denied reading update cache	Reset BITS service permissions; check SoftwareDistribution folder ACLs
0x8024402C	Cannot reach WSUS server	Verify WSUS URL in registry/GPO; check firewall; ping WSUS server
0x80244022	HTTP 403 from WSUS	WSUS IIS authentication — check anonymous auth and app pool identity
0x80244010	Too many redirects	WSUS URL mismatch — HTTP vs HTTPS, port number wrong
0xC1800118	WSUS metadata issue	Run WSUS server cleanup wizard; decline superseded updates

Verify the WSUS server URL on the client

:: Check current WSUS configuration from registry
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUServer
reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate" /v WUStatusServer

:: Force a client-side update detection
wuauclt /detectnow

:: On Windows 10/11 and Server 2016+, use usoclient instead
usoclient StartScan

WSUS server-side: Console is slow or clients stopped reporting

If all clients stopped checking in around the same time, or the WSUS console takes minutes to load, the root cause is almost always a bloated WSUS database. Microsoft's default WSUS installation uses Windows Internal Database (WID), and it requires periodic maintenance that Microsoft doesn't enable by default.

Check the WSUS database size

:: Connect to the WSUS database (WID instance)
sqlcmd -S np:\\.\pipe\MICROSOFT##WID\tsql\query -E

-- Check database sizes
SELECT name, size*8/1024 AS 'Size_MB' FROM sys.databases ORDER BY size DESC
GO

Run the WSUS Server Cleanup Wizard

In the WSUS console: Options > Server Cleanup Wizard. Check all options. If it times out or hangs, the database is too bloated for the wizard — go straight to the manual SQL maintenance below.

Manual WSUS database maintenance (the real fix)

This script re-indexes the WSUS database and removes obsolete update metadata. It's the most impactful fix for a slow WSUS server and should be run on a schedule.

:: Save as WSUS-Maintenance.sql and run against the WID instance
:: sqlcmd -S np:\\.\pipe\MICROSOFT##WID\tsql\query -i WSUS-Maintenance.sql -E

USE SUSDB

-- Re-index all fragmented indexes
EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD'
GO

-- Update statistics
EXEC sp_updatestats
GO

-- Remove obsolete update revisions (run WSUS cleanup wizard first, or this takes a long time)
DECLARE @var1 INT
EXEC spDeclineExpiredUpdates
EXEC spDeclineSupersededUpdates
EXEC spDeleteUnneededRevisions
GO

Clients not reporting to WSUS

If specific clients stopped checking in but the WSUS server is healthy, the problem is usually on the client side. Check these in order:

1. Verify the GPO is applying

:: On the client machine
gpresult /R

:: Look for:
:: "HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate"
:: WUServer should show your WSUS URL

2. Force a check-in and review the client event log

:: Force detection
usoclient StartScan

:: Check the Windows Update event log
:: Event Viewer > Applications and Services > Microsoft > Windows > WindowsUpdateClient > Operational

:: Or via PowerShell
Get-WinEvent -LogName "Microsoft-Windows-WindowsUpdateClient/Operational" -MaxEvents 50 |
    Where-Object {$_.LevelDisplayName -ne 'Information'} |
    Select-Object TimeCreated,Id,Message |
    Format-List

3. Check if the client can reach the WSUS server

:: Test connectivity to WSUS server (replace with your WSUS hostname and port)
Test-NetConnection -ComputerName wsus01.domain.com -Port 8530

:: If WSUS uses HTTPS
Test-NetConnection -ComputerName wsus01.domain.com -Port 8531

:: Test via browser on the client: http://wsus01.domain.com:8530/selfupdate/iuident.cab
:: Should download a small .cab file — if it errors, the problem is network/IIS

Setting up recurring WSUS maintenance

WSUS requires regular cleanup to stay healthy. The minimum maintenance schedule that prevents database bloat:

• Weekly: Run the Server Cleanup Wizard (can be scripted)
• Monthly: Decline superseded updates in the console
• Quarterly: Full SQL re-index using the script above

# Script the cleanup wizard via PowerShell (run as scheduled task on WSUS server)
[reflection.assembly]::LoadWithPartialName("Microsoft.UpdateServices.Administration") | Out-Null
$wsus = [Microsoft.UpdateServices.Administration.AdminProxy]::GetUpdateServer()
$cleanupScope = New-Object Microsoft.UpdateServices.Administration.CleanupScope
$cleanupScope.DeclineSupersededUpdates = $true
$cleanupScope.DeclineExpiredUpdates = $true
$cleanupScope.CleanupObsoleteUpdates = $true
$cleanupScope.CompressUpdates = $true
$cleanupScope.CleanupUnneededContentFiles = $true
$cleanupScope.CleanupObsoleteComputers = $true
$wsus.GetCleanupManager().PerformCleanup($cleanupScope)

Summary

Windows Update problems almost always fall into one of three buckets: a corrupted client-side cache (fix with service reset and DISM), a bloated WSUS database (fix with SQL maintenance and the cleanup wizard), or a broken client-to-WSUS connection (fix by verifying GPO, firewall, and IIS). The WSUS database maintenance is the most commonly skipped step — and the one that causes the most pain over time. Set up the scheduled cleanup script and you'll never have a WSUS console that takes five minutes to open again.