0x80245001 and 0x80245003: the update redirector cab cannot be used

Fix it now

Before any scan happens, Windows Update downloads and parses a small signed cabinet that tells it which update service applies to this device. Microsoft publishes 0x80245001 as the redirector XML failing to load, and 0x80245003 as a downloaded cab whose redirector ID is lower than the cached one. Clear the cache, fix the clock, and stop anything rewriting the download.

w32tm /resync
net stop wuauserv
net stop bits
net stop cryptsvc
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
ren C:\Windows\System32\catroot2 catroot2.old
net start cryptsvc
net start bits
net start wuauserv

1. Check the result of the time sync with w32tm /query /status. The cab is signed, and a machine whose clock is badly wrong will reject content that is perfectly valid.
2. Scan again from Settings, Windows Update and see whether the code changes. A different code after the cache reset means you have moved past this stage.
3. If it persists, look at what sits between the device and Microsoft. Ask for the update endpoints to be excluded from TLS inspection rather than merely allowed through.
4. Confirm what the machine account itself uses for a proxy with netsh winhttp show proxy, since the browser’s settings do not apply to the update client.

Renaming SoftwareDistribution and catroot2 is safe. Windows rebuilds both on the next scan; you lose cached downloads and the history list, and nothing that is already installed.

If the scan now runs, you are past it. The next section explains what that cabinet does and why three of the five codes on this page have no published meaning.

Why it happens

A Windows client has no single hard-coded update server. It works out which service applies to it, and the answer arrives as a signed cabinet file that Microsoft’s documentation calls the redirector cab. The client downloads it, parses it and caches it, and everything that happens afterwards depends on having read it successfully. When that step fails the scan does not degrade, it stops, which is why these codes appear immediately rather than partway through.

Microsoft publishes four codes in this range. 0x80245001 is WU_E_REDIRECTOR_LOAD_XML, meaning the redirector XML document could not be loaded into the DOM class. 0x80245002 is WU_E_REDIRECTOR_S_FALSE, the document is missing required information. 0x80245003 is WU_E_REDIRECTOR_ID_SMALLER, the redirector ID in the downloaded cab is lower than the one in the cached cab. 0x80245FFF is the catch-all. That is the whole published list.

The other three codes carried by this article, 0x80245004, 0x80245005 and 0x80245008, are not in it. They appear in neither the current Windows Update error reference nor the archived Windows Update Agent result code list, and they return nothing on Microsoft Learn. They are redirector-range results, so the stage they belong to is not in doubt, but their exact meanings are not published and this page will not invent them. Diagnose them the same way as the documented three: clock, cache, and whatever is between the client and the service.

Full reference

What Microsoft actually publishes for this range

0x80245004, 0x80245005 and 0x80245008 are absent from that table and from the archived Windows Update Agent result codes. If you find a page that states their meanings confidently, check whether it cites a vendor source. In our checks, none does.

Reading 0x80245003 correctly

This one has a specific and useful meaning that is easy to misread. The client compares the redirector ID in the cab it just downloaded against the ID in the cab it already holds, and refuses the new one if it is lower. In practice that means the machine has been handed older service-location data than it already has. The two situations that produce it are a stale cached copy that needs clearing, and something in the path serving a cached older response. Renaming SoftwareDistribution deals with the first; the second is a caching proxy question.

The two proxy configurations, and which one matters

Windows keeps separate proxy settings for interactive users and for services. Your browser uses the per-user settings with your credentials attached. Windows Update runs in the machine context and uses the WinHTTP configuration, with no user, no credentials and no way to answer a prompt. That single difference explains most cases where browsing works and updating does not, and it is why checking the browser proves nothing here.

Log evidence worth collecting

• Run Get-WindowsUpdateLog and read the newest scan. The redirector stage is early and is named clearly in the trace.
• Compare a working and a failing machine on the same subnet before assuming the network is at fault.
• On a machine behind an inspecting appliance, check whether the certificate presented for the update endpoints is the vendor’s or the appliance’s.
• If the device is managed, confirm whether a management platform registered a service that has since been removed. That registration is what the client is trying to resolve.

What this is not

This stage happens before any conversation with an update server, so a reachable WSUS box tells you nothing about it. It is also not component store corruption, despite the fact that DISM and sfc are worth running: they repair the pieces that validate the signature, which is a supporting cause rather than the failure itself. And it is not a licensing problem, so nothing here is fixed by buying anything.

Every code this article covers

Confirm the fix worked

1. A scan in Settings, Windows Update completes rather than stopping immediately.
2. A new SoftwareDistribution folder exists with a current timestamp.
3. w32tm /query /status shows the machine synchronised with a sensible source.
4. One update installs end to end and appears in the update history.

Questions people ask about this