0x8024402C and 0x8024401C: the proxy your browser uses is not the proxy Windows Update uses

A device stops patching. The error is 0x8024402C. Somebody opens a browser on that exact device, loads a public website, and it works first time. The conclusion arrives within seconds and it is wrong: "the network is fine, so it must be the Windows Update client."

It is almost never the client. What just happened is that you tested a completely different HTTP stack from the one the update agent uses.

The Windows Update agent is a service running under the Local System account. It reaches its endpoints through WinHTTP, the machine-wide HTTP stack. Your browser reaches its endpoints through the per-user WinINET configuration. Those two are stored separately, configured separately, and on a corporate device they routinely disagree.

So the browser test proves nothing. Worse, it sends you off resetting update components on a machine whose network path was broken the whole time.

The problem: the browser works and the agent still cannot scan

Start with what the two codes actually say, because their names carry the entire diagnosis.

Microsoft's Windows Update error code list by component files both of these under Protocol Talker errors. Protocol Talker is the component that talks to the update service over HTTP. Not the installer. Not the component store. The wire.

Read that table as a family, not as nine unrelated problems. Every one of them is the agent failing at the network layer, and seven of the nine name a proxy or an HTTP status a proxy hands back.

That matters because these codes tend to migrate. A device that shows 0x8024402C on Monday shows 0x8024401C on Tuesday and 0x8024401B on Wednesday, and each new code sends a different engineer down a different path. They are one fault: the agent's HTTP request is not arriving intact at the update endpoint.

The specific reason 0x8024402C is so misleading is in its own definition. "The proxy server or target server name can't be resolved." Two very different faults share one code. Either the agent cannot resolve fe3.delivery.mp.microsoft.com because DNS is broken or the endpoint is not permitted, or it cannot resolve the proxy hostname it was told to use, because that hostname is wrong, stale, or only resolvable from a different DNS suffix. Microsoft's dedicated support article for this code is explicit that on a device using an intranet service such as WSUS, "the computer can't connect to the WSUS server".

And 0x8024401C is quieter and nastier. An HTTP 408 means something answered. A TCP connection was established, a request was started, and then it stalled. That is a proxy that accepted the connection and could not, or would not, complete it upstream. It is the signature of a proxy in the path that you did not know was in the path.

Why it happens: WinHTTP is not WinINET, and the agent is SYSTEM

Two HTTP stacks, two separate configurations

Windows ships two general-purpose client HTTP stacks and they have different jobs. Both are in System32, both were verified present on the device used for this article, and confusing them is the single most common cause of a wasted afternoon.

Every version and description above was read off a live Windows 11 Enterprise device, build 26200.9168, running 25H2. Check binary paths yourself before quoting them: on that same device usocore.dll was not present in either System32 or SysWOW64, which is a good reminder that "well-known" Windows file locations are worth one Test-Path before they go into a runbook.

The agent's security context is the whole story

The registry entries for the Windows Update service on that device read as follows. ImagePath is C:\WINDOWS\system32\svchost.exe -k netsvcs -p, ObjectName is LocalSystem, and the Parameters\ServiceDll value is C:\WINDOWS\system32\wuaueng.dll.

So the update agent is a DLL hosted in a shared svchost group, running as Local System. It has no user profile, no HKCU hive of its own to speak of, and no interactive session to prompt in. Microsoft's article on how the Windows Update client determines which proxy server to use states the consequence directly: because the service "runs under the Local System account" and "affects system-wide level configuration", WinHTTP is the appropriate stack rather than WinINET.

The same article then narrows the options to two, and this is the sentence that resolves most of these cases. The Automatic Updates service can discover a proxy server only by one of the following: the proxy is manually configured using the Netsh command, or WPAD settings are configured in the DNS options or the DHCP options of the network environment.

That is the complete list. Not "also whatever is in Internet Options". Not "also whatever the user's PAC file says". Two mechanisms.

The fallback exists, but it is narrow and it is off by default

There is a fallback, and knowing its exact shape stops a lot of arguing. Microsoft documents the order separately for two classes of URL.

1. For Windows Update scan URLs - the SimpleAuth Web Service and Client Web Service used for update detection - the system proxy (WinHTTP) is attempted first. If the agent fails to reach the service due to certain proxy, service or authentication error codes, then the user proxy is attempted, which Microsoft describes as "generally, it's the signed-in user IE settings or WinINet".
2. For Windows Update URLs that are not used for update detection, such as the ones used for reporting, the order inverts. The user proxy is attempted first, and the system proxy is the fallback.

Two consequences follow. First, reporting can succeed while detection fails, so a device can look alive in a console and still never scan. Second, on an HTTP intranet update service that user-proxy fallback for detection is disabled by default, which is why the browser working changes nothing.

The switch that controls it is the SetProxyBehaviorForUpdateDetection policy, surfaced in Group Policy as the element "Select the proxy behavior for Windows Update client for detecting updates" inside Specify intranet Microsoft update service location. Microsoft's Policy CSP - Update reference gives two values: 0, the default, "Only use system proxy for detecting updates", and 1, "Allow user proxy to be used as a fallback if detection using system proxy fails". It also carries an explicit warning that setting it to 1 "exposes your environment to potential security risk and makes scans unsecure".

Why importing the browser proxy usually does not help either

The obvious next move is netsh winhttp import proxy source=ie, and it is worth knowing its documented limitation before you rely on it. The netsh winhttp reference describes it as importing proxy settings into the WinHTTP configuration from the Internet Explorer settings, and Microsoft's guidance elsewhere is clear that this covers the manual section of the Internet Settings proxy configuration only. Automatic detection and configuration scripts are not imported.

In other words: if your fleet is proxied by PAC file or by WPAD - which is most fleets - there is nothing in the manual section to import. The command runs, reports success, and copies an empty configuration.

WPAD in SYSTEM context, and the authenticated proxy wall

WPAD is the other supported route, and it is genuinely supported. WinHTTP will locate a proxy by querying a DHCP option or by locating a DNS record. Two things break it in practice.

The first is that WPAD has to be resolvable and reachable in the service's context, at the time the service asks. On the device used here, WinHTTP was configured to auto-detect and there was no WPAD record to find, which is exactly the shape of a network that produces 0x8024402C as soon as direct egress is blocked. The verification section below shows the real output.

The second is authentication. If your proxy demands credentials, the agent gets HTTP 407 and surfaces 0x8024401B. Look at the documented syntax of the command that sets the machine proxy: netsh winhttp set proxy [proxy-server=]<server name> [bypass-list=]<hosts list>. There is nowhere to put a username or a password, because there is not supposed to be one. A machine-level, non-interactive service has no user credential to offer. If your proxy will not accept the computer account for integrated authentication, the update agent cannot pass it, and no amount of resetting update components will change that.

Certificate pinning: why TLS inspection breaks Windows Update specifically

This is the one that survives every other fix and gets blamed on the client for months.

Microsoft's Windows Update security article describes the metadata exchange as HTTPS over TCP 443, and states that those connections are certificate-pinned. The pin does two things: it validates the server certificate normally, and it validates that "the certificate's issuer is validated as genuine Microsoft Windows Update". The article then says the connection fails if the issuer is unexpected or is not a valid Windows Update intermediate certificate.

Now put a break-and-inspect proxy in the path. It terminates TLS and presents a certificate issued by your inspection CA. That CA is trusted by the device - you deployed it, it works everywhere else - and it is still not a genuine Windows Update intermediate. The pin rejects it. The scan fails. Nothing on the device is broken, and no client-side change can fix it.

Microsoft's instruction is direct: because these connections are certificate-pinned, "it's important that TLS proxies pass these connections without interception". That is an exemption list on the proxy, not a setting on the endpoint.

The endpoints, and the RANGE request requirement

Do not invent hostnames for a firewall ticket. Microsoft publishes the list. The table below is the set given in the "Device can't access update files" section of the Windows Update issues troubleshooting article, using Windows 10 version 2004 as its worked example. Microsoft notes in the same place that the specific endpoints can vary between Windows client versions, and points to the per-version connection endpoint articles for the authoritative list for your build.

One more requirement that is easy to miss and produces a completely different symptom. Microsoft documents that "Windows Update uses WinHttp with Partial Range requests (RFC 7233) to download updates", and therefore "proxy servers on the network must support HTTP RANGE requests". A proxy that strips or refuses RANGE gives you 0x80d05001 DO_E_HTTP_BLOCKSIZE_MISMATCH, or high CPU while updates download, rather than a Protocol Talker error. Microsoft suggests permitting RANGE specifically for *.download.windowsupdate.com, *.dl.delivery.mp.microsoft.com and *.delivery.mp.microsoft.com, and warns that if you cannot allow RANGE you will download more content than needed because delta patching stops working.

How to verify: eight reads, in order, before any change

Everything below is read-only. Nothing here restarts a service, clears a cache, or deletes a folder. Work through it in order and you will land on a cause rather than a guess.

Step 1. Get the code from the event log, not from the Settings page

The Settings UI rounds errors off. The event log does not. All of the following were observed on the live test device in the Microsoft-Windows-WindowsUpdateClient/Operational channel.

On the test device, over the last 500 events in that channel, Event 26 appeared 412 times, Event 41 seventy-five times, Event 31 twice, and Event 25 eleven times. That distribution is what a healthy device looks like: overwhelmingly successful detection with a small tail of transient failures. A device with a proxy fault inverts it.

Step 2. Read the machine proxy. This is the whole ballgame

Two commands. The first is the classic view, the second is the modern JSON view that also tells you whether auto-detect is on and whether per-user settings are in play.

Read that carefully, because it is the exact configuration that produces the confusion this article is about.

ProxyIsEnabled: false means no static WinHTTP proxy is set. AutoConfigIsEnabled: false means no PAC URL is configured at machine level. AutoDetect: true means WinHTTP is relying entirely on WPAD. And PerUserProxySettings: true tells you the per-user WinINET configuration is live and separate - which is exactly the setting your browser was reading when you decided the network was fine.

Three possible answers and three different conclusions. If it says "Direct access (no proxy server)" on a network that requires a proxy, the agent has no path and 0x8024402C is the expected result. If it names a proxy, verify that hostname resolves and that the port is right. If it says auto-detect with no static proxy, your entire update path depends on WPAD, and you should go and prove WPAD works.

Step 3. Prove or disprove WPAD

If AutoDetect is true and no static proxy is set, one DNS query decides whether the agent has any chance at all.

Do this from the device with the fault, on the network with the fault, and check the DNS suffix search list while you are there. A WPAD record that resolves from the corporate suffix and not from a VPN-assigned suffix is a very common cause of "it only fails for remote users".

Step 4. Compare the machine proxy with the user proxy, side by side

Now make the mismatch visible rather than arguing about it. The per-user WinINET configuration lives under HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings. On the test device the only proxy value present there was ProxyEnable, set to 0; ProxyServer, ProxyOverride and AutoConfigURL were all absent.

That is the comparison to put in your ticket. Machine level: auto-detect, no static proxy, WPAD unresolvable. User level: proxy disabled. Two independent configurations, neither of which gets the agent to an endpoint on a proxied network. If instead you find AutoConfigURL populated at user level and nothing at machine level, you have found the fault in one read.

Step 5. Read the WindowsUpdate policy key before you assume the target

You cannot diagnose a transport failure without knowing which server the agent is trying to reach. All of the following live directly under one key.

Two nuances from the live device that will save you a wrong turn. First, the AU subkey underneath this key existed but contained no values at all. An empty AU key is not evidence of legacy Automatic Updates management, so a detection script that does nothing more than Test-Path on it will misclassify the device. Enumerate the values, not the key. Second, UseWUServer - the REG_DWORD that actually switches the client over to WSUS - lives in that AU subkey, not in the parent. Absent UseWUServer with a populated WUServer is a real and confusing half-configured state.

Step 6. Ask the agent which service it is actually bound to

Policy tells you intent. This tells you reality. Microsoft's troubleshooting article documents this exact COM query as the way to determine the source of updates in use.

If a "Windows Server Update Service" row appears here, stop testing Microsoft endpoints and start testing your WSUS host, on its configured port, from this device. If it does not appear and you expected it to, the policy has not applied and the transport error is a symptom of a policy problem.

Step 7. Test from SYSTEM context, not from your own session

This is the step that everybody skips and it is the step that settles the argument. Your elevated PowerShell prompt still runs as you, with your session's network context. The agent does not.

Microsoft's own Sysinternals tool does this properly. PsExec documents -s as "Run the remote process in the System account" and -i as running the program so that it interacts with the desktop of the specified session.

Microsoft's support article for 0x8024402C asks for exactly this pair of checks - use ping or nslookup to confirm the device can reach other devices and resolve DNS addresses correctly - before anything else. Doing it as SYSTEM is what makes the answer meaningful.

Step 8. Read the agent's own transport log

Microsoft's Windows Update log files reference documents that since Windows 8.1 the client logs through Event Tracing for Windows into C:\Windows\Logs\WindowsUpdate, and that Get-WindowsUpdateLog merges and converts those .etl trace files into a single readable WindowsUpdate.log. On the test device that directory held rolling files named in the pattern WindowsUpdate.20260810.085032.624.2.etl, around 520 KB each.

Two component names matter for this investigation. MISC is general service information, which is where the raw WinHTTP failures land, and ProtocolTalker is client-server sync. Filter to those two and the noise disappears.

Microsoft publishes the exact log signature for this failure in its 0x8024402C article. These lines are Microsoft's own published excerpt, not a reconstruction.

If your own log shows SendRequestUsingProxy, a proxy is in the path and the proxy or target name did not resolve. If it shows the request going direct and still failing, the endpoint itself is unreachable or blocked. Those are two different tickets, and this log line is what separates them.

The fix: machine proxy, bypass list, and the proxy's own behaviour

Order matters. Capture state, then make the smallest change that matches the evidence you gathered.

Capture the current WinHTTP configuration first

The netsh winhttp reference documents dump as creating "a script containing the current context configuration" that "can be saved to a file and used to restore settings if they're altered". That is your rollback, and it costs one command.

On the bypass list, use only what is documented. The reference says the list is semicolon-separated hostnames or IP addresses that should be accessed directly, and that an empty string bypasses the proxy for all short-name, non-fully-qualified hosts. If you are running WSUS, the WSUS host belongs on that list - sending intranet update traffic out through a corporate proxy and back is a reliable way to generate 0x8024401C timeouts for no benefit.

If it is WSUS, fix the target before you touch the proxy

Correct WUServer and WUStatusServer so they name a host this device can resolve, on the port the service actually listens on. Microsoft's WSUS deployment guidance uses https://wsus01:8531 as its worked example for the intranet update service. Confirm UseWUServer is set in the AU subkey, then re-run step 6 and confirm a "Windows Server Update Service" row appears.

Then fix the proxy, because most of the remaining work is not on the endpoint

Four asks for whoever owns the proxy, all of them backed by Microsoft documentation rather than opinion.

1. Exempt the Windows Update hostnames from TLS interception. The metadata connections are certificate-pinned and Microsoft states that TLS proxies must pass them without interception. This is not negotiable by configuration on the client.
2. Permit HTTP RANGE requests for the content hostnames. Without RANGE you lose delta patching and gain a lot of bandwidth.
3. Keep the protocols as published. HTTP endpoints over HTTP, HTTPS endpoints over HTTPS. Microsoft's warning that the connection will fail if you swap them is literal.
4. Decide the authentication story. If the proxy requires an interactive user credential, the update agent will never pass it, because there is nowhere in the documented netsh winhttp set proxy syntax to supply one. Either allow the computer account through integrated authentication, or exempt these hostnames from proxy authentication.

What not to do

Do not reset the SoftwareDistribution folder. Do not run sfc /scannow or a DISM restore against a transport error - the component store is not involved in a failed HTTP request, and DISM /RestoreHealth needs the very network path that is broken. Do not disable the firewall service; Microsoft documents that stopping it produces its own distinct download failures. And do not re-image. A device that cannot resolve a proxy name will not resolve it any better after a rebuild.

Proof it worked: a clean detection cycle, in the log

One successful click on "Check for updates" is not proof, because the interactive path can use the signed-in user's context. Proof is the agent completing a detection cycle on its own schedule, in its own context, and saying so.

Three signals, and you need all three. The proxy configuration reads back the way you set it. Event 26 appears without a matching Event 25. And a real KB installs, which proves the content endpoints and RANGE support work as well as the metadata path.

Watch the default detection interval before you declare victory. Microsoft documents that where the detection frequency policy is not configured, Windows checks for updates at a default interval of 22 hours, and where it is configured the actual wait is 80 to 100 percent of the value set. So a quiet event log twenty minutes after your change means nothing. Give it a full cycle, or trigger a scan and then confirm the unattended cycle behind it.

One last honesty check on your own evidence. Event 26 reads "Windows Update successfully found 0 updates" on a fully patched device, and on the test device that is exactly what 412 of those events said. Zero updates found is a success, not a failure. The failure you were chasing does not produce Event 26 at all - it produces Event 25 and a Protocol Talker code, and now you know how to read it.

References

• Windows Update error code list by component - the authoritative definitions of 0x8024402C, 0x8024401C, 0x8024401B, 0x80244011 and 0x80240030, grouped under Protocol Talker errors.
• How the Windows Update client determines which proxy server to use - the Local System context, the two-mechanism proxy discovery rule, the system-proxy-then-user-proxy order for scan URLs and the inverted order for reporting URLs.
• Error code 0x8024402C when you try to install a Windows update or a Feature on Demand - the err.exe definition, the ping and nslookup first steps, and the published SendRequestUsingProxy log excerpt.
• netsh winhttp - full syntax for show proxy, show advproxy, set proxy, set advproxy, import proxy source=ie, reset proxy and dump, including the bypass-list rules and the JSON property names.
• Windows Update security - certificate pinning on the metadata exchange, the instruction that TLS proxies must pass these connections without interception, and why content download uses plain HTTP with signature and hash validation instead of TLS.
• Windows Update issues troubleshooting - the HTTP/proxy section, the RFC 7233 RANGE requirement, the published endpoint table and the warning about swapping HTTP for HTTPS.
• Manage additional Windows Update settings - WUServer and WUStatusServer as REG_SZ under the WindowsUpdate policy key, UseWUServer in the AU subkey, and the 22-hour default detection interval.
• Policy CSP - Update - SetProxyBehaviorForUpdateDetection values 0 and 1, the Group Policy element name, and Microsoft's security warning about enabling user-proxy fallback.
• Windows Update log files - the ETL location under C:\Windows\Logs\WindowsUpdate, Get-WindowsUpdateLog, and the component name list including MISC and ProtocolTalker.
• Step 4: Configure Group Policy settings for automatic updates - the "Specify intranet Microsoft update service location" options and the https://wsus01:8531 worked example.
• PsExec - the -s switch documented as running the process in the System account, which is how you test the agent's context rather than your own.