0x80240034 and 0x80240438: the download fails, or an update endpoint is unreachable

Fix it now

0x80240034 is WU_E_DOWNLOAD_FAILED and says only that the update failed to download. 0x80240438 is more useful: Microsoft publishes it as WU_E_PT_ENDPOINT_UNREACHABLE, which names a specific problem. Start with the network path, because one of the two codes is already telling you that is where the fault is.

net stop wuauserv
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
net start wuauserv

1. Before touching the client, test the path. If downloads fail on your network and succeed on a phone hotspot, you have proved the fault is not on the machine and everything below about the agent is wasted effort.
2. Get the network team to allow the endpoints Microsoft publishes for Windows Update, by host name and not by address: windowsupdate.microsoft.com and *.windowsupdate.microsoft.com, update.microsoft.com and *.update.microsoft.com, windowsupdate.com and *.windowsupdate.com, download.windowsupdate.com and *.download.windowsupdate.com, download.microsoft.com, wustat.windows.com and *.wustat.windows.com, and ntservicepack.microsoft.com.
3. Run the built-in troubleshooter. On Windows 11 it is Settings, System, Troubleshoot, Other troubleshooters, then Run next to Windows Update. On Windows 10 it is Settings, Update and Security, Troubleshoot, Additional troubleshooters, then Windows Update.
4. Reset the agent’s store with the commands above and rescan. The first scan is slow because the datastore is being rebuilt from nothing.
5. If a mixture of unrelated codes keeps appearing, repair the servicing components: DISM.exe /Online /Cleanup-image /Restorehealth, then sfc /scannow, then restart.

Do not build the firewall exception on IP addresses. The published list is host names because the addresses behind them change, and an address-based allow list stops working within weeks.

If updates download and install, you are finished. If not, the next section explains what each of the four codes is actually reporting.

Why it happens

A Windows Update download has two halves that can fail independently: reaching the service that hands out content locations, and reaching the content. The codes on this page sit in both halves, and the useful move is to read which one you have rather than to reset the agent by reflex.

0x80240034 is WU_E_DOWNLOAD_FAILED, and Microsoft’s published description is exactly four words long: update failed to download. It carries no diagnosis. 0x80240438 is the one worth reading carefully – Microsoft publishes it as WU_E_PT_ENDPOINT_UNREACHABLE alongside 0x8024402C and 0x8024500C, in an article about machines that cannot reach the content they need because they are isolated from the internet or managed by a policy that redirects them. That is a network statement, and it should send you to the firewall rather than to the client.

0x80240FFF is WU_E_UNEXPECTED: an operation failed for reasons not covered by another error code. It is a catch-all, but it has one documented specific: on a WSUS server where the Upgrades classification was enabled before hotfix 3095113 was installed, update synchronisation fails with it. If you are seeing it on a WSUS-managed estate rather than on a single machine, look at the server.

0x8024A105 is not published anywhere by Microsoft. It appears in this article’s code list because people see it, and the honest answer is that no vendor source states a meaning. Treat it as a scan or install operation that ended without a documented reason, diagnose it from Get-WindowsUpdateLog rather than from the code, and do not let anyone tell you it means something specific about scheduled scans.

Full reference

Reading the four codes

Where the log lives and how to read it

Since Windows 8.1 the update client writes Event Tracing for Windows traces rather than a plain text log. WindowsUpdate.log is produced from them on demand: run Get-WindowsUpdateLog in PowerShell and it writes a static copy, which does not keep updating afterwards. The traces themselves sit under C:\ProgramData\USOShared\Logs and the produced log is written to C:\Windows\Logs\WindowsUpdate. Run the cmdlet again for a fresh copy after each attempt.

Proving where the fault is before you change anything

1. Scan and note whether updates are listed. A scan that works proves the service path is fine.
2. Start a download and watch whether the percentage moves at all. Nothing at all points at reachability; a stall part way points at the content path or an inspecting appliance.
3. Repeat on a different connection. A hotspot is the fastest way to separate machine from network.
4. Only then reset the client. Resetting first destroys the evidence and changes nothing when the fault is a firewall rule.

Installing a single update by hand

Where one specific KB refuses to download and everything else works, fetch it from the Microsoft Update Catalog and install it directly. That is a supported installation – the same package the service would have delivered – and it tells you something useful: if the manual install succeeds, the content is retrievable and your problem is delivery rather than the update. It does not fix the delivery path, so treat it as a diagnostic and a stopgap rather than a resolution.

When downloads work but installs still fail

• Check free space on the system volume. A download that completes and an install that fails is a different family of codes entirely.
• Check whether the machine owes a restart from a previous update; a pending operation blocks the next one.
• Check whether an endpoint agent is quarantining files under SoftwareDistribution, using the vendor’s own exclusions rather than turning protection off.
• Read the log for the specific update rather than the overall result, because the aggregate code is usually the least specific thing available.

Every code this article covers

Confirm the fix worked

1. A scan from Settings, Windows Update both lists and installs updates rather than stopping at the download.
2. Update history shows the previously failing KB as installed.
3. Get-HotFix lists the update with a current date on the machine you fixed.
4. A second machine on the same network behaves the same way, which is what tells you the fix was the network rather than one client.
5. The result holds through a restart and a subsequent scheduled scan.

Questions people ask about this