0x80240030 and 0x80240021: update operations time out behind a bad proxy

Fix it now

Microsoft publishes 0x80240030 as WU_E_INVALID_PROXY_SERVER, the format of the proxy list was invalid, and 0x80240021 as WU_E_TIME_OUT, the operation did not complete because it timed out. The first is a parsing failure on the machine, the second is something too slow to finish. Neither has anything to do with your Windows licence.

netsh winhttp show proxy
netsh winhttp reset proxy
net stop wuauserv
net start wuauserv

1. Read what the machine account is actually using. This is not your browser’s proxy: Windows Update runs in the machine context and reads the WinHTTP configuration.
2. Test a scan with no proxy at all after the reset. If it works, the definition was the problem and you can set a correct one.
3. If a proxy really is required, set it in the documented form, for example netsh winhttp set proxy proxy-server="http=proxy.example.local:8080;https=proxy.example.local:8080" bypass-list="*.example.local;<local>".
4. Have the update endpoints allowed without authentication and excluded from TLS inspection, because a machine-context request cannot answer a credentials prompt.
5. Rescan and watch what changes. A timeout that becomes a slow but successful scan points at server capacity rather than at client configuration.

Microsoft now marks netsh winhttp show proxy and set proxy as deprecated in favour of show advproxy and set advproxy, which take their settings as JSON. The older commands still work and are what most estates are documented around.

If the scan completes in a sensible time, stop here. Below is why there are two proxy configurations, and which of the five codes points at the client and which at the server.

Why it happens

Windows keeps separate proxy settings for interactive users and for services. Your browser uses the per-user settings, complete with your credentials. 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 one difference accounts for most cases where browsing works perfectly and updating does not, and it is why checking the browser proves nothing.

0x80240030 is raised when that machine-level configuration cannot be interpreted at all. Microsoft’s wording is that the format of the proxy list was invalid. A typing mistake in the netsh string, a policy pushing a malformed value, or an automatic configuration script returning something unusable will all produce it. The client is not saying the proxy is unreachable; it is saying it cannot tell what it has been asked to use.

0x80240021 is a different complaint entirely. The exchange started and did not finish in time. That happens with a proxy that stalls, a configuration script that has to be fetched from somewhere slow before every request, or an update server carrying more catalogue than it can serve promptly. On managed networks the server end is the usual culprit, and the supporting codes tell you which end to look at: 0x80244010 is WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS, the number of round trips to the server exceeded the maximum limit, which is a server-side symptom, while 0x8024001F is WU_E_NO_CONNECTION, no network connection was available, which is a client-side one.

Full reference

The five codes, and which end each accuses

The proxy commands, current and deprecated

Microsoft’s netsh documentation now carries deprecation notices on two of the commands most estates are built around. They still function, and the replacements take a different kind of argument, so it is worth knowing both.

<local> in a bypass list means every short-name host. Getting your own update server into that list is usually the single most effective change on a managed network, because it stops internal traffic taking a slow trip through an external proxy.

Separating a slow server from a broken client

1. Run the scan from a client on the same subnet as the update server with no proxy configured. If that is fast, the fault is in the path.
2. Compare the timing across several clients. One slow machine is a client problem; every machine at nine in the morning is a scheduling and capacity problem.
3. Look at the update server’s application pool for repeated recycles during scan windows.
4. Check the size of the catalogue. A server that has never had superseded updates declined makes every client do more work on every scan.
5. Only after that, start changing things on the client.

Where the evidence lives

One thing worth knowing about the server

If the timeouts trace back to a WSUS server, it is worth knowing where that product stands. Microsoft lists Windows Server Update Services among the features no longer in development, while confirming that existing capabilities and content remain available for current deployments. That is not a reason to rip it out this week, but it is a reason not to invest heavily in tuning an ageing instance when the estate could move to a serviced alternative.

Every code this article covers

Confirm the fix worked

1. netsh winhttp show proxy reports the configuration you intended for the machine context.
2. A scan in Settings, Windows Update completes within a reasonable time.
3. One update installs end to end and appears in the update history.
4. On a managed network, several clients complete a scan in the same window rather than one at a time.

Questions people ask about this