Skip to content

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

Your vault is empty.

Free Fix 0x80190194

0x80190194 and 0x801901F4: HTTP errors while downloading update content

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

Fix it now

Every code here is an HTTP status wrapped in an HRESULT. 0x80190194 is a 404 and 0x801901F4 is a 500, so the download stack reached something and that something answered badly. Find out what answered before you change anything on the client.

Run these in an elevated Command Prompt on the failing client

netsh winhttp show proxy
netsh winhttp import proxy source=ie
  1. Read the last three digits of the code as decimal. 0x194 is 404, 0x1F4 is 500, 0x190 is 400, 0x197 is 407, 0x1F6 is 502 and 0x1F8 is 504. That tells you whose problem it is before you touch a setting.
  2. A 407 means a proxy wants credentials the system account does not have. Fix the proxy exception or the authentication, not the client’s update settings.
  3. A 404 from a managed update server usually means the content is not on it. Check the server holds the files, not just the metadata.
  4. A 500, 502 or 504 is the server or something in front of it failing. Look at the server’s own logs before assuming the client is at fault.
  5. Confirm the client is using the proxy you think it is. The update stack runs as a service and uses the system-wide WinHTTP configuration, not the browser’s.

Resetting the client is the wrong first move for every code in this article. The client did its job: it made a request and got an answer it could not use.

If content downloads you can stop here. If not, the next section explains which layer each status implicates and how to prove it.

Why it happens

Scanning and downloading are separate steps that can fail independently. A client asks a service what it needs, gets a list, and then fetches the files. The codes in this article all come from the second step, and they are unusual among Windows Update errors in that they tell you exactly what happened at the wire: something answered, with a status, and the status is in the code.

That makes them easy to read once you know the trick. Take the last three hexadecimal digits and convert them to decimal, and you have the HTTP status. 0x80190194 is HTTP_E_STATUS_NOT_FOUND, a 404. 0x801901F4 is HTTP_E_STATUS_SERVER_ERROR, a 500. 0x80190190 is a 400, 0x80190197 is a 407 with proxy authentication required, 0x801901F6 is a 502 and 0x801901F8 is a 504.

The practical consequence is that the client is rarely the thing to repair. A 404 says the content is not where the client was told it would be. A 407 says something in the path wants credentials. A 500, 502 or 504 says a server or a gateway failed. Each of those points somewhere different, and clearing the client’s cache addresses none of them.

A proxy is intercepting the request and wants credentials

You have this one if 0x80190197, or 400 and 404 responses that look nothing like what the server would send.

  1. Check what the system-wide proxy is with netsh winhttp show proxy.
  2. Set it correctly, or import the user’s configuration with netsh winhttp import proxy source=ie.
  3. Ask the network team to exempt update traffic from authentication, since the update stack runs as a service rather than as a signed-in user.
  4. Confirm the proxy supports HTTP RANGE requests. The download stack relies on them, and a proxy that strips or refuses them breaks content transfer even when everything else looks correct.

Reach the published endpoints over the protocol each one expects. Substituting HTTPS for HTTP on an endpoint that is documented as HTTP is a common and self-inflicted cause of these codes.

The managed update server has metadata but not content

You have this one if 0x80190194 from clients pointed at your own update server, with the update visible in the console.

  1. Confirm the server is configured to store update files locally, and that the files have actually downloaded.
  2. Check the server’s disk space, since a full volume stops content synchronising while metadata continues.
  3. Look at the server’s web logs for the requested path and see what it returned.
  4. Resynchronise the affected updates and let the content download before pointing clients at them again.

The update server’s application pool is unhealthy

You have this one if 0x801901F4 from many clients at once, and an administration site that is slow or unavailable.

  1. Check the WsusPool application pool. A stopped pool produces HTTP Error 503, the service is unavailable, on the administration site, which is a useful confirmation.
  2. Raise the pool’s private memory limit if it is being recycled under load. The default is 1843200 KB and Microsoft’s guidance is to raise it to 4000000 KB, or to 8000000 KB or higher depending on the environment.
  3. Restart the pool and watch whether it stays up under client load.
  4. Read the web server logs and the HTTP error log to see which requests were failing.

A gateway or inspection device in the path is failing

You have this one if 0x801901F6 or 0x801901F8, which are 502 and 504, and which no origin server produced.

  1. Identify every device between the client and the content: proxy, gateway, inspection appliance, load balancer.
  2. Test from a machine on the same subnet without the device in the path, if that is possible.
  3. Check for TLS inspection that is failing on the update endpoints, which produces gateway errors rather than clean refusals.
  4. Ask for the device’s own logs for the same timestamp rather than inferring from the client.

Full reference

Reading the code as a status

Code HTTP Constant
0x80190190 400 HTTP_E_STATUS_BAD_REQUEST
0x80190194 404 HTTP_E_STATUS_NOT_FOUND
0x80190197 407 HTTP_E_STATUS_PROXY_AUTH_REQ
0x801901F4 500 HTTP_E_STATUS_SERVER_ERROR
0x801901F6 502 HTTP_E_STATUS_BAD_GATEWAY
0x801901F8 504 HTTP_E_STATUS_GATEWAY_TIMEOUT

The pattern holds beyond these six. Anything starting 0x8019 is an HTTP status in the last three digits, so a code you have not seen before is usually readable on sight rather than needing a search.

What the network has to allow

  • Reach the Microsoft update endpoints over the protocol each one is documented to use. Some are HTTP and some are HTTPS, and swapping them is not an improvement.
  • Allow HTTP RANGE requests through every proxy in the path. Content transfer depends on them, and a proxy that refuses them produces failures that look like server problems.
  • Avoid TLS inspection on update endpoints unless you have confirmed it works, since a failed inspection produces gateway errors rather than a clear refusal.
  • Remember that the update stack runs as a service. Authentication schemes that assume an interactive user will fail with a 407.
  • On a managed estate, allow the clients to reach the update server over the port and protocol the server is actually published on.

Where the answers are logged

Log What it tells you
The update server’s web logs Which request the client made and which status was returned
The HTTP error log on the server Requests rejected before they reached the application
The client’s Delivery Optimization and update logs What the client asked for and what it received
The proxy or gateway’s own logs Whether the request ever reached the server at all

Comparing the client’s view with the server’s is the whole job here. A 404 the client reports and the server never logged means something in between answered on the server’s behalf, which changes the investigation entirely.

On testing the server by hand

Confirm the update server’s administration website responds, and read its application pool state, rather than fetching a service URL in a browser and drawing conclusions from what comes back. A raw service endpoint is not designed to be browsed and its response tells you very little about whether clients can download content.

When it is only some clients

  • Compare a working and a failing client’s system-wide proxy configuration. That single difference explains most partial outages.
  • Check whether the failing clients sit behind a different gateway or in a different site.
  • Look for a policy applying a proxy or a different update server to one group and not another.
  • Check the time on the failing clients. Skew produces authentication failures that surface as HTTP errors rather than as clock errors.

Every code this article covers

Code What it points at Source
0x80190194 HTTP_E_STATUS_NOT_FOUND: the server answered HTTP 404 Microsoft Learn
0x801901F4 HTTP_E_STATUS_SERVER_ERROR: the server answered HTTP 500 Microsoft Learn
0x80190190 HTTP_E_STATUS_BAD_REQUEST: the server answered HTTP 400 Microsoft Learn
0x80190197 HTTP_E_STATUS_PROXY_AUTH_REQ: the server answered HTTP 407, proxy authentication required Microsoft Learn
0x801901F6 HTTP_E_STATUS_BAD_GATEWAY: the server answered HTTP 502 Microsoft Learn
0x801901F8 HTTP_E_STATUS_GATEWAY_TIMEOUT: the server answered HTTP 504 Microsoft Learn

Confirm the fix worked

  1. The client downloads and installs the update that was failing.
  2. netsh winhttp show proxy reports the configuration the network expects for a service account.
  3. On a managed estate, the update server’s web logs show successful responses for the content requests.
  4. The server’s administration website responds normally and its application pool is running.

Questions people ask about this

Why does resetting the Windows Update client not help?

Because the client is not the thing that failed. Every code here is an HTTP status returned by something the client contacted, so the client made a well-formed request and received an answer it could not use. Renaming SoftwareDistribution changes nothing about what the server or the proxy will say next time.

How do I read one of these codes without looking it up?

Take the last three hexadecimal digits and convert them to decimal. 0x194 is 404, 0x1F4 is 500, 0x197 is 407. The prefix 0x8019 marks it as an HTTP status, so the whole family is readable on sight once you have done it once.

My update server shows the update, so why do clients get a 404?

Because metadata and content are separate. A server can hold the description of an update while the files themselves have not downloaded, usually because of disk space or an interrupted synchronisation. Confirm the files are present on the server rather than trusting the console listing.

Could TLS inspection be causing this?

It is a strong candidate for 502 and 504 codes, and for odd 400 responses. Inspection appliances that cannot complete a handshake with an update endpoint tend to produce gateway errors rather than clean refusals. Test with the endpoints exempted and compare.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

Free Fix 0x80D0000A and 0x80D02003: Delivery Optimization job errors stop update downloads Free Fix 0x800F0984 and 0x800F0988: delta patch errors when installing updates License Error 0x800F081E and 0xC1900204: the update does not apply to this edition Free Fix 0x80070017 and 0x8007045D: install media read errors during Windows Setup
← Back to Knowledge Base