Skip to content

Network failures should decode WinINet HRESULTs and include actionable proxy context #6319

Open
Feature
#6321
Open
Network failures should decode WinINet HRESULTs and include actionable proxy context#6319
Feature
#6321
Labels
Issue-FeatureThis is a feature request for the Windows Package Manager client.

Description

@starSumi
starsumi (starSumi)
opened on Jun 23, 2026

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

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-FeatureThis is a feature request for the Windows Package Manager client.

    Type

    Feature

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
     blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
Network failures should decode WinINet HRESULTs and include actionable proxy context · Issue #6319 · microsoft/winget-cli · GitHub
    Skip to content
    Network failures should decode WinINet HRESULTs and include actionable proxy context #6319
    Open
    Feature
    #6321
    Open
    Network failures should decode WinINet HRESULTs and include actionable proxy context#6319
    Feature
    #6321
    Labels
    Issue-FeatureThis is a feature request for the Windows Package Manager client.
    Description
    @starSumi
    starsumi (starSumi)
    opened on Jun 23, 2026
    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
    This issue is intended as a narrow diagnostic enhancement, not another connectivity bug report.
    Metadata
    Metadata
    Assignees
    No one assigned
      Labels
      Issue-FeatureThis is a feature request for the Windows Package Manager client.
      Type
      Feature
      Projects
      No projects
      Milestone
      No milestone
      Relationships
      None yet
      Development
      No branches or pull requests
      Issue actions
      
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Network failures should decode WinINet HRESULTs and include actionable proxy context · Issue #6319 · microsoft/winget-cli · GitHub
      Skip to content
      Network failures should decode WinINet HRESULTs and include actionable proxy context #6319
      Open
      Feature
      #6321
      Open
      Network failures should decode WinINet HRESULTs and include actionable proxy context#6319
      Feature
      #6321
      Labels
      Issue-FeatureThis is a feature request for the Windows Package Manager client.
      Description
      @starSumi
      starsumi (starSumi)
      opened on Jun 23, 2026
      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
      This issue is intended as a narrow diagnostic enhancement, not another connectivity bug report.
      Metadata
      Metadata
      Assignees
      No one assigned
        Labels
        Issue-FeatureThis is a feature request for the Windows Package Manager client.
        Type
        Feature
        Projects
        No projects
        Milestone
        No milestone
        Relationships
        None yet
        Development
        No branches or pull requests
        Issue actions
        
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Network failures should decode WinINet HRESULTs and include actionable proxy context · Issue #6319 · microsoft/winget-cli · GitHub
        Skip to content
        Network failures should decode WinINet HRESULTs and include actionable proxy context #6319
        Open
        Feature
        #6321
        Open
        Network failures should decode WinINet HRESULTs and include actionable proxy context#6319
        Feature
        #6321
        Labels
        Issue-FeatureThis is a feature request for the Windows Package Manager client.
        Description
        @starSumi
        starsumi (starSumi)
        opened on Jun 23, 2026
        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
        This issue is intended as a narrow diagnostic enhancement, not another connectivity bug report.
        Metadata
        Metadata
        Assignees
        No one assigned
          Labels
          Issue-FeatureThis is a feature request for the Windows Package Manager client.
          Type
          Feature
          Projects
          No projects
          Milestone
          No milestone
          Relationships
          None yet
          Development
          No branches or pull requests
          Issue actions
          
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
Network failures should decode WinINet HRESULTs and include actionable proxy context · Issue #6319 · microsoft/winget-cli · GitHub
          Skip to content
          Network failures should decode WinINet HRESULTs and include actionable proxy context #6319
          Open
          Feature
          #6321
          Open
          Network failures should decode WinINet HRESULTs and include actionable proxy context#6319
          Feature
          #6321
          Labels
          Issue-FeatureThis is a feature request for the Windows Package Manager client.
          Description
          @starSumi
          starsumi (starSumi)
          opened on Jun 23, 2026
          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
          This issue is intended as a narrow diagnostic enhancement, not another connectivity bug report.
          Metadata
          Metadata
          Assignees
          No one assigned
            Labels
            Issue-FeatureThis is a feature request for the Windows Package Manager client.
            Type
            Feature
            Projects
            No projects
            Milestone
            No milestone
            Relationships
            None yet
            Development
            No branches or pull requests
            Issue actions
            
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
Network failures should decode WinINet HRESULTs and include actionable proxy context · Issue #6319 · microsoft/winget-cli · GitHub
            Skip to content
            Network failures should decode WinINet HRESULTs and include actionable proxy context #6319
            Open
            Feature
            #6321
            Open
            Network failures should decode WinINet HRESULTs and include actionable proxy context#6319
            Feature
            #6321
            Labels
            Issue-FeatureThis is a feature request for the Windows Package Manager client.
            Description
            @starSumi
            starsumi (starSumi)
            opened on Jun 23, 2026
            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
            This issue is intended as a narrow diagnostic enhancement, not another connectivity bug report.
            Metadata
            Metadata
            Assignees
            No one assigned
              Labels
              Issue-FeatureThis is a feature request for the Windows Package Manager client.
              Type
              Feature
              Projects
              No projects
              Milestone
              No milestone
              Relationships
              None yet
              Development
              No branches or pull requests
              Issue actions
              
, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
})();
Network failures should decode WinINet HRESULTs and include actionable proxy context · Issue #6319 · microsoft/winget-cli · GitHub
              Skip to content
              Network failures should decode WinINet HRESULTs and include actionable proxy context #6319
              Open
              Feature
              #6321
              Open
              Network failures should decode WinINet HRESULTs and include actionable proxy context#6319
              Feature
              #6321
              Labels
              Issue-FeatureThis is a feature request for the Windows Package Manager client.
              Description
              @starSumi
              starsumi (starSumi)
              opened on Jun 23, 2026
              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
              This issue is intended as a narrow diagnostic enhancement, not another connectivity bug report.
              Metadata
              Metadata
              Assignees
              No one assigned
                Labels
                Issue-FeatureThis is a feature request for the Windows Package Manager client.
                Type
                Feature
                Projects
                No projects
                Milestone
                No milestone
                Relationships
                None yet
                Development
                No branches or pull requests
                Issue actions