Large installer download over a throttled HTTP proxy stalls silently - no error code, no timeout, no further log output #6677

Relevant area(s)

WinGet CLI

Relevant command(s)

winget upgrade

Brief description of your issue

winget upgrade --id Microsoft.VisualStudioCode --exact downloads a large installer (256,382,880 bytes) through a local HTTP proxy (127.0.0.1:3067) that throttles a single connection to roughly 64 KB/s. In most runs the download neither completes nor fails: the log stops at [CORE] WinINet downloading from url: ... and never grows again, the CLI prints nothing further, there is no error code, no timeout, no "download failed" message, and a partial file is left in %TEMP%\WinGet\....

In other runs of the same command against the same kind of proxy bottleneck, the failure is reported (Downloader.cpp(270) ... Exception ... 8A15002E, then one retry, then give up after roughly 3 minutes). So the identical condition is either surfaced as an opaque HRESULT or not surfaced at all.

Steps to reproduce

1. On Windows, configure an HTTP proxy at 127.0.0.1:3067 (WinHTTP proxy is set to it, and Internet Settings ProxyServer is set to it) that throttles a single connection to roughly 64 KB/s.

2. Run:

   winget upgrade --id Microsoft.VisualStudioCode --exact
   

3. The installer being fetched is:

   https://vscode.download.prss.microsoft.com/dbazure/download/stable/dcd3ad6e368fbe19d03f37054a40dbaf40d676f4/VSCodeUserSetup-x64-1.145.3.exe
   

   The manifest declares 256,382,880 bytes; the CDN returns Content-Length: 256382880 and Accept-Ranges: bytes (verified with curl -I).

4. Wait. No progress output, no completion, no failure.

I ran this four times on 2026-11-12 (11:01, 11:11, 11:46, 11:56 local time). All four log files end on the exact same line and then stop growing.

Expected behavior

Either the download completes, or it fails with an actionable error: a stalled-progress/timeout detection that reports why it gave up (proxy throttling, read timeout, connection reset, ...) and a documented error code. A download that is making no progress for several minutes should not be indistinguishable from a download that is working.

Actual behavior

The last line written to the log is:

2026-11-12 11:56:36.448 <I> [CORE] WinINet downloading from url: https://vscode.download.prss.microsoft.com/dbazure/download/stable/dcd3ad6e368fbe19d03f37054a40dbaf40d676f4/VSCodeUserSetup-x64-1.145.3.exe

Nothing after it — ever. The log file stays at ~6 KB. There is no <E> line, no 0x... code, no Failed to download, no timeout notice, and no console output. The run had to be aborted manually.

A partial file was left behind: 152,043,520 bytes (145 MiB) of the expected 256,382,880 bytes (244 MiB), under %TEMP%\WinGet\Microsoft.VisualStudioCode.1.145.3\ named after the installer SHA256.

Full tail of one of the stalled attempts (WinGet-2026-11-12-11-56-35.009.log, end of file):

2026-11-12 11:56:36.446 <I> [CLI ] Generated temp download path: C:\Users\<user>\AppData\Local\Temp\WinGet\Microsoft.VisualStudioCode.1.145.3\a6eea952f0bfc29a2e4905c36f9c0cbcc7d2eb311091cf85baaf53d523edd315
2026-11-12 11:56:36.446 <I> [CLI ] Installer download headers: 
2026-11-12 11:56:36.446 <I> [CORE] Downloading to path: C:\Users\<user>\AppData\Local\Temp\WinGet\Microsoft.VisualStudioCode.1.145.3\a6eea952f0bfc29a2e4905c36f9c0cbcc7d2eb311091cf85baaf53d523edd315
2026-11-12 11:56:36.447 <I> [CORE] Started applying motw to C:\Users\<user>\AppData\Local\Temp\WinGet\Microsoft.VisualStudioCode.1.145.3\a6eea952f0bfc29a2e4905c36f9c0cbcc7d2eb311091cf85baaf53d523edd315 with zone: 3
2026-11-12 11:56:36.448 <I> [CORE] Finished applying motw
2026-11-12 11:56:36.448 <I> [CORE] WinINet downloading from url: https://vscode.download.prss.microsoft.com/dbazure/download/stable/dcd3ad6e368fbe19d03f37054a40dbaf40d676f4/VSCodeUserSetup-x64-1.145.3.exe

For contrast, an earlier attempt at 1.145.2 through the same proxy did produce an error, and then gave up (WinGet-2026-11-11-20-47-25.635.log):

2026-11-11 20:47:56.407 <I> [CORE] WinINet downloading from url: https://vscode.download.prss.microsoft.com/dbazure/download/stable/c4453f8ea430795f941c1b2ff6c9321135a74a02/VSCodeUserSetup-x64-1.145.2.exe
2026-11-11 20:51:09.152 <E> [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Downloader.cpp(270)\WindowsPackageManager.dll!00007FFC01A38379: (caller: 00007FFC01A33B4E) Exception(1) tid(697c) 8A15002E 
2026-11-11 20:51:09.152 <I> [CLI ] Failed to download, waiting a bit and retry. Url: https://vscode.download.prss.microsoft.com/dbazure/download/stable/c4453f8ea430795f941c1b2ff6c9321135a74a02/VSCodeUserSetup-x64-1.145.2.exe
2026-11-11 20:51:09.668 <I> [CORE] WinINet downloading from url: https://vscode.download.prss.microsoft.com/dbazure/download/stable/c4453f8ea430795f941c1b2ff6c9321135a74a02/VSCodeUserSetup-x64-1.145.2.exe
2026-11-11 20:51:19.299 <E> [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Downloader.cpp(270)\WindowsPackageManager.dll!00007FFC01A38379: (caller: 00007FFC01A33B4E) Exception(2) tid(697c) 8A15002E 
2026-11-11 20:51:19.301 <E> [CLI ] Caught wil::ResultException: C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Downloader.cpp(270)\WindowsPackageManager.dll!00007FFC01A38379: (caller: 00007FFC01A33B4E) Exception(2) tid(697c) 8A15002E 

Note the two attempts took 3m13s and 10s respectively before erroring out, and 8A15002E is not something a user can act on. But at least it terminated. The 1.145.3 runs never terminate.

Network measurements

Same machine, same URL, taken around the time of the failures:

• Through the proxy, single connection: ~64 KB/s.
• Direct to the same CDN, single connection: 65-255 KB/s.
• Direct, 4 parallel connections: ~250 KB/s each, and the rates add up.
• Direct, 16 parallel connections (manual downloader): the 244 MiB file completes in seconds; SHA256 matches the manifest.

So the file is reachable and correct; a single stream is simply too slow, and winget's single-stream download apparently sits in a state it never escapes.

Environment

winget --info

Windows Package Manager v1.29.380
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.26300.9818
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.29.380.0

Proxy:
netsh winhttp show proxy
  Proxy Server(s) :  127.0.0.1:3067
HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings
  ProxyServer : 127.0.0.1:3067

Windows 11 Pro, version 26H2, OS build 26300.9818, x64.

Workaround (works, but should not be necessary)

1. Download the installer manually (multi-connection) and verify SHA256 = a6eea952f0bfc29a2e4905c36f9c0cbcc7d2eb311091cf85baaf53d523edd315.
2. Copy it to %TEMP%\WinGet\Microsoft.VisualStudioCode.1.145.3\a6eea952f0bfc29a2e4905c36f9c0cbcc7d2eb311091cf85baaf53d523edd315.
3. Run winget upgrade --id Microsoft.VisualStudioCode --exact again — winget reuses the cached file, verifies the hash and the upgrade succeeds.

Requests

1. Detect a stalled download and report it. A download that has made no progress for N minutes (or that hits a WinINet read timeout) should abort with a clear message naming the cause and the effective proxy, instead of returning without any output at all. Right now the "stalled" and "working" states are indistinguishable from the CLI, and the same root cause yields either silence or a bare 8A15002E.
2. Consider chunked / multi-connection downloads for large installers. The CDN advertises Accept-Ranges: bytes, and in this environment parallel connections give additive throughput (4 x ~250 KB/s vs ~64 KB/s single-stream). For several-hundred-MB installers behind a throttled proxy, a single connection is effectively unusable.

Related, but not duplicates: #2124 (slow single-stream downloads / fall back to WinINet), #6319 (decode WinINet HRESULTs and surface proxy context).