Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

Free Fix 0x80072EE2

0x80072EE2 and 0x80072EFD: Windows Update times out reaching Microsoft

10 min read Updated October 4, 2026 Windows Update & Setup

Fix it now

All five codes come from the internet layer beneath Windows Update rather than from the update client. 0x80072EE2 is WinINet’s timeout, 0x80072EFD its failure to connect at all. Microsoft’s own mitigation is to make sure the device can reach the Windows Update endpoints and that no firewall rule or proxy is blocking them.

Run these on the failing machine, in an elevated Command Prompt

netsh winhttp show proxy
nslookup windowsupdate.microsoft.com
  1. Read the proxy output first. The update service runs as the system account and uses the WinHTTP proxy, which is not the one configured in your browser. If it names a server that no longer exists, that is your answer.
  2. Test the path out with Test-NetConnection windowsupdate.microsoft.com -Port 443 in PowerShell. A failure here is a network problem and no client-side work will help.
  3. Have the endpoints Microsoft publishes allowed by host name: 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.
  4. Exempt those host names from TLS inspection. An appliance that terminates and re-signs the session is the most common reason a machine times out on the corporate network and succeeds on any other.
  5. Fix the system proxy if it is wrong: netsh winhttp reset proxy to go direct, netsh winhttp import proxy source=ie to take the working user configuration, or netsh winhttp set proxy with a bypass list.
  6. Retest on a different connection, such as a phone hotspot, before spending a day on firewall rules.

A proxy that demands user authentication cannot work for a service running as the system account. These endpoints have to be permitted without user credentials.

If the scan completes, you are done. If it does not, the next section separates the timeout codes from the ones that name the server.

Why it happens

Windows Update does not implement its own transport. It asks WinINet to open an HTTPS session, and when that fails the WinINet error is passed straight back to you with an 0x8007 style wrapper on it. Four of the five codes here are WinINet errors and the fifth is the update client’s SOAP layer reporting the same thing one level up. None of them is a statement about Windows Update itself.

0x80072EE2 is ERROR_INTERNET_TIMEOUT, decimal 12002, ‘The request has timed out’. Microsoft’s own description in the Windows Update error list is an inability to scan because of a connectivity issue to Windows Update, Configuration Manager or WSUS, and the mitigation is to check with the network team that the device can reach the update sources. 0x80072EFD is ERROR_INTERNET_CANNOT_CONNECT, 12029, ‘The attempt to connect to the server failed’, with the published mitigation of making sure no firewall rules or proxies block Microsoft download URLs.

The other two WinINet codes are more specific and worth separating out. 0x80072F84 is ERROR_INTERNET_SERVER_UNREACHABLE, 12164, ‘The website or server indicated is unreachable’ – a statement about the named host rather than about the network in general. 0x80072F78 is ERROR_HTTP_INVALID_SERVER_RESPONSE, 12152, ‘The server response could not be parsed’, which means something did answer and what it sent was not usable. That one points squarely at an appliance in the middle rather than at a blocked port.

0x80244004 is WU_E_PT_SOAPCLIENT_CONNECT, the SOAP client failing to connect to the server. It is the update client’s own way of saying the same thing the WinINet codes say. Seeing it alongside them is confirmation, not a second problem.

One thing this article used to claim and no longer does: the system clock is not a published cause of any of these five codes. A wrong clock does break TLS, but Microsoft attributes the client-side TLS failure to a different code – 0x80072F8F, WININET_E_DECODING_FAILED, which it describes as TLS 1.2 not being configured correctly. Check the clock as part of the certificate validation path, not because these codes mean it.

An inspecting appliance is breaking the session

You have this one if Timeouts or resets on the corporate network only, and the same machine updates normally on any other connection. 0x80072F78 in particular.

  1. Exempt the published Windows Update host names from TLS inspection on the appliance.
  2. Exempt by host name, never by address; the addresses behind these names change constantly.
  3. Retest a download as well as a scan, because they take different paths.
  4. If the appliance cannot exempt by name, route update traffic around it rather than weakening inspection everywhere.

The system account has the wrong proxy, or none

You have this one if Browsing works while signed in but the update service cannot connect, and netsh winhttp show proxy shows nothing useful.

  1. Note the current value before changing it.
  2. Set the right one with netsh winhttp set proxy proxy-server="proxy.example.local:8080" bypass-list="*.example.local".
  3. Or import the working user configuration with netsh winhttp import proxy source=ie.
  4. Or clear it with netsh winhttp reset proxy if the machine should connect directly.
  5. Restart the Windows Update service and retest.

Name resolution fails or is intercepted

You have this one if nslookup fails for a Microsoft host name, or returns an internal address for one.

  1. Check the resolvers configured on the adapter with ipconfig /all.
  2. Clear the resolver cache with ipconfig /flushdns and retest.
  3. An internal server answering with its own address for external names is a filtering appliance. Fix it there, or exempt the update host names.
  4. Test against a resolver you know is clean to prove where the difference is.

The named server genuinely is unreachable

You have this one if 0x80072F84, or 0x80244004 against a WSUS host name rather than a Microsoft one.

  1. Confirm which server the client is trying to reach. On a managed machine read WUServer under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate.
  2. Test that host and port directly with Test-NetConnection.
  3. If it is a WSUS server that no longer exists, the fix is in the policy object, not on the client.

The machine cannot negotiate a modern session

You have this one if An old, unpatched Windows build fails while current machines on the same network succeed.

  1. Bring the machine up to date offline first, using packages from the Microsoft Update Catalog, so current transport security is available to it.
  2. Confirm the root certificate store is current; an outdated store fails validation against modern certificates and a wrong clock makes it worse.
  3. If it cannot be brought current, plan its replacement rather than weakening the network to accommodate it.

Full reference

The five codes, and what each one actually says

Code Decimal Published text
0x80072EE2 12002 The request has timed out
0x80072EFD 12029 The attempt to connect to the server failed
0x80072F78 12152 The server response could not be parsed
0x80072F84 12164 The website or server indicated is unreachable
0x80244004 – WU_E_PT_SOAPCLIENT_CONNECT: the SOAP client failed to connect

Commands that narrow it down

Command What it tells you
netsh winhttp show proxy The proxy the update service will actually use
netsh winhttp reset proxy Sets WinHTTP back to DIRECT
netsh winhttp import proxy source=ie Copies the Internet Explorer proxy settings into WinHTTP
nslookup windowsupdate.microsoft.com Whether the update host names resolve, and to what
Test-NetConnection host -Port 443 Whether a session can be opened at all
ipconfig /flushdns Clears cached resolution before a retest
Get-WindowsUpdateLog Produces a readable log naming the URL that failed

Where the clock does and does not matter

A machine whose clock is badly wrong cannot validate a server certificate, and the session fails. That is real, and w32tm /resync is the fix – note that /resync takes /computer:, /nowait, /rediscover and /soft and nothing else, so a /force you may have seen elsewhere is simply rejected. What is not true is that the codes on this page mean the clock is wrong. Check it because it is quick, not because the code said so.

Proving it is the network in under two minutes

  1. Run the scan on the corporate connection and note the code.
  2. Move the same machine to an unfiltered connection – a phone hotspot is ideal – and scan again.
  3. If it works there, stop touching the machine. Every remaining step belongs to whoever runs the firewall or the proxy.
  4. If it fails there too, the fault is on the machine: proxy configuration, resolver, certificate store or transport security.

What to hand the network team

  • The published host name list, not an address range.
  • The requirement that these names are exempt from TLS inspection.
  • The fact that the client runs as the system account, so any proxy that requires user authentication will fail regardless of what the signed-in user can browse.
  • The specific code, because 0x80072F78 says something answered and 0x80072F84 says nothing did – and those are two different conversations.

Every code this article covers

Code What it points at Source
0x80072EE2 ERROR_INTERNET_TIMEOUT (12002): the request has timed out; Microsoft ties it to a connectivity issue reaching Windows Update, Configuration Manager or WSUS Microsoft Learn
0x80072EFD ERROR_INTERNET_CANNOT_CONNECT (12029): the attempt to connect to the server failed Microsoft Learn
0x80072F78 ERROR_HTTP_INVALID_SERVER_RESPONSE (12152): the server response could not be parsed Microsoft Learn
0x80244004 WU_E_PT_SOAPCLIENT_CONNECT: the SOAP client failed to connect to the server Microsoft Learn
0x80072F84 ERROR_INTERNET_SERVER_UNREACHABLE (12164): the website or server indicated is unreachable Microsoft Learn

Confirm the fix worked

  1. netsh winhttp show proxy reports the configuration you intended, whether that is a named proxy or DIRECT.
  2. Test-NetConnection on port 443 against an update host succeeds from the affected subnet.
  3. A scan from Settings, Windows Update completes and updates download rather than only listing.
  4. The result holds on the corporate network, not only on the test connection.
  5. A second machine on the same subnet behaves the same way after the network change.

Questions people ask about this

Does any of this involve buying a licence?

No. All five codes are transport failures. A machine with a perfect licence produces every one of them when a proxy is wrong or an appliance is inspecting the session.

Is exempting update traffic from TLS inspection safe?

The content Windows Update delivers is signed and verified by the client, so the inspection is adding little for that traffic and is frequently what breaks it. Exempt the published host names specifically rather than opening a category.

Why does the hotspot test matter so much?

Because it separates machine from network in one step. Almost every hour lost to these codes is spent resetting an update client that was never the problem.

Is a wrong clock the cause?

Not of these codes. Microsoft attributes the client-side TLS problem to a different code, 0x80072F8F, described as TLS 1.2 not configured correctly. Fix the clock anyway with w32tm /resync, but do not expect it to be the answer here.

Can antivirus cause these codes?

Yes, where the product proxies or inspects HTTPS locally. It sits in exactly the same position as a network appliance. Test with the web protection component paused if your policy allows, and use the vendor’s documented exclusions rather than turning the product off.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix 0xC1900107 and 0xC190010A: leftover setup state, and setup command lines it will not accept Free Fix 0x8024402C: the update client cannot resolve the WSUS or proxy name License Error 0x800B0100 and 0x800B0109: update signature and certificate failures License Error 0x80070070 – 0x50011: the upgrade runs out of disk space and rolls back
← Back to Knowledge Base