Network failures should decode WinINet HRESULTs and include actionable proxy context

[starSumi]

Brief description of your issue

When winget fails to refresh a source or download through WinINet, the user-facing error can be too low-level to act on:

InternetOpenUrl() failed.
0x80072efd : unknown error

In the case below, the failure was caused by local proxy configuration, but the output did not mention the effective proxy, the source URL being refreshed, or any recovery path such as checking proxy settings or using --no-proxy when available.

Steps to reproduce

Environment:

winget: v1.28.240
PowerShell: 7.6.3
Installed package: Microsoft.PowerShell 7.6.3.0
Source: winget -> https://cdn.winget.microsoft.com/cache

Proxy state:

WinHTTP proxy: 127.0.0.1:7090
WinINet/user proxy: 127.0.0.1:7091
Git proxy: http://127.0.0.1:7091
127.0.0.1:7090: not listening
127.0.0.1:7091: listening, but TLS through it fails after CONNECT

Run:

winget upgrade --id Microsoft.PowerShell --source winget --accept-package-agreements --accept-source-agreements --disable-interactivity

Expected behavior

The error should expose enough context to diagnose the failure. For example:

• Decode 0x80072efd as a WinINet/Win32 connection failure instead of unknown error.
• Include the source name or URL involved, where safe.
• Include whether a winget proxy/default proxy is active, where safe and without leaking credentials.
• Suggest relevant recovery actions, such as checking proxy settings or trying --no-proxy if enabled.

Actual behavior

尝试更新源失败： winget
执行此命令时发生意外错误：
InternetOpenUrl() failed.
0x80072efd : unknown error

The same URL succeeds when bypassing the proxy:

curl.exe -I --noproxy "*" https://cdn.winget.microsoft.com/cache/source.msix

HTTP/1.1 200 OK
Content-Length: 17357706

The same URL through the local proxy fails:

curl.exe -I --proxy http://127.0.0.1:7091 https://cdn.winget.microsoft.com/cache/source.msix

HTTP/1.1 200 Connection established
curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed

Source-level triage

Local checkout: microsoft/winget-cli at 5eb96e8.

Relevant paths:

• src/AppInstallerCommonCore/Downloader.cpp
  • logs WinINet downloading from url
  • reads Network().GetProxyUri()
  • calls InternetOpenUrl(...)
  • throws THROW_LAST_ERROR_IF_NULL_MSG(urlFile, "InternetOpenUrl() failed.")
• src/AppInstallerSharedLib/Errors.cpp
  • GetUserPresentableMessageForHR prints 0x... : ...
  • unknown external HRESULTs fall through to std::system_category().message(hr)
• src/AppInstallerCLICore/Workflows/WorkflowBase.cpp
  • catches wil::ResultException
  • writes UnexpectedErrorExecutingCommand plus GetUserPresentableMessage(re)

0x80072efd is HRESULT_FROM_WIN32(ERROR_INTERNET_CANNOT_CONNECT). The current rendering appears to pass the full HRESULT to the system category instead of decoding the Win32 code via HRESULT_CODE(hr), which can produce unknown error.

Suggested fix direction

Minimal:

• In Errors.cpp, when an HRESULT has FACILITY_WIN32, use HRESULT_CODE(hr) for the system message.

Better diagnostic:

• In Downloader.cpp, enrich InternetOpenUrl() failure context with URL/source and proxy mode.
• Redact credentials if a proxy URI is printed.

Tests:

• Extend src/AppInstallerCLITests/Errors.cpp for HRESULT_FROM_WIN32(ERROR_INTERNET_CANNOT_CONNECT) and assert the user message is no longer unknown error.
• Add a workflow-level test using a download hook that throws HRESULT_FROM_WIN32(ERROR_INTERNET_CANNOT_CONNECT) and asserts the output includes a useful diagnostic.

Related issues / PRs

• InternetOpenUrl() failed. 0x80072efd : unknown error #566: exact InternetOpenUrl() failed. 0x80072efd report, closed
• InternetOpenURL() Failed. 0x80072efd : unknown error. happens every time I execute a winget command #5412: duplicate of InternetOpenUrl() failed. 0x80072efd : unknown error #566
• Provide Friendly error for 0x80072ee7 : unknown error #1546: friendly error for 0x80072ee7 : unknown error, open
• Proxy options support #190 / Add support for proxies #190 #4203: proxy support
• WinGet download doesn't work through a proxy #5030 / Allows setting WinGet proxy setting as SFS Client Proxy #5054: proxy path related behavior

This issue is intended as a narrow diagnostic enhancement, not another connectivity bug report.