"winget upgrade" not completing

Question

"winget upgrade" not completing

Closed this issue 9 days ago · 25 comments

wbpayne22902 commented 11 days ago

Relevant area(s)

WinGet CLI

Relevant command(s)

winget upgrade

Brief description of your issue

I am running winget on Windows 11 25H2 build 10.0.26200.7015 and on trying a winget upgrade it takes longer than expected then throws the error Failed in attempting to update the source: winget. It was working earlier today for me.

Steps to reproduce

Run winget upgrade

Expected behavior

It should complete without error

Actual behavior

It shows the error message Failed in attempting to update the source: winget

Environment

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

Windows: Windows.Desktop v10.0.26200.7015
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.27.350.0

Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads
Configuration Modules              %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

Answer 1 · 2025-10-28T01:07:51.000Z

The following issues might be duplicates:

#5366
#5815

AI-generated content by genai-issue-dedup may be incorrect.

Answer 2 · 2025-10-28T01:10:03.000Z

Experiencing the same issue.
winget logs indicate Internal server error (500) when Winget tries to fetch its source packages from:
https://cdn.winget.microsoft.com/cache/source2.msix
https://cdn.winget.microsoft.com/cache/source.msix

Answer 3 · 2025-10-28T01:14:46.000Z

I can also verify that trying to download those two MSIX files using Microsoft Edge also runs into issues. Thank you for confirming this isn't just my environment @evilcougar.

Answer 4 · 2025-10-28T01:21:08.000Z

This is in my WinGet.log file:

2025-10-28 12:16:48.084 [CORE] Found matching extension.
2025-10-28 12:16:48.087 [CORE] Retrieving headers from url: https://cdn.winget.microsoft.com/cache/source2.msix
2025-10-28 12:16:48.276 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Downloader.cpp(314)\WindowsPackageManager.dll!00007FFB5DF5E90E: (caller: 00007FFB5E196632) Exception(1) tid(5298) 801901F4 Internal server error (500).

2025-10-28 12:16:48.276 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(125)\WindowsPackageManager.dll!00007FFB5E2746DF: (caller: 00007FFB5E1994D1) LogHr(1) tid(5298) 801901F4 Internal server error (500).
    Msg:[PreIndexedPackageUpdateCheck failed on location: https://cdn.winget.microsoft.com/cache/source2.msix -- C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Downloader.cpp(314)\WindowsPackageManager.dll!00007FFB5DF5E90E: (caller: 00007FFB5E196632) Exception(1) tid(5298) 801901F4 Internal server error (500).
] 

2025-10-28 12:16:48.276 [CORE] Retrieving headers from url: https://cdn.winget.microsoft.com/cache/source.msix
2025-10-28 12:16:48.341 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Downloader.cpp(314)\WindowsPackageManager.dll!00007FFB5DF5E90E: (caller: 00007FFB5E196632) Exception(2) tid(5298) 801901F4 Internal server error (500).

2025-10-28 12:16:48.341 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(125)\WindowsPackageManager.dll!00007FFB5E2746DF: (caller: 00007FFB5E1994D1) LogHr(2) tid(5298) 801901F4 Internal server error (500).
    Msg:[PreIndexedPackageUpdateCheck failed on location: https://cdn.winget.microsoft.com/cache/source.msix -- C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Downloader.cpp(314)\WindowsPackageManager.dll!00007FFB5DF5E90E: (caller: 00007FFB5E196632) Exception(2) tid(5298) 801901F4 Internal server error (500).
] 

2025-10-28 12:16:48.341 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(96)\WindowsPackageManager.dll!00007FFB5E2721B5: (caller: 00007FFB5E17D6DD) LogHr(3) tid(5298) 801901F4 Internal server error (500).
    Msg:[C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Downloader.cpp(314)\WindowsPackageManager.dll!00007FFB5DF5E90E: (caller: 00007FFB5E196632) Exception(1) tid(5298) 801901F4 Internal server error (500).
] 

2025-10-28 12:16:48.341 [REPO] Source add/update failed, waiting 9077 milliseconds and retrying: winget

Answer 5 · 2025-10-28T01:25:36.000Z

Ha ha not funny:

Answer 6 · 2025-10-28T02:51:43.000Z

Getting the same thing here. Even doing something like "winget search Google.Chrome" is taking an incredibly long time to come back, and when it does there is a message at the top reading "Failed in attempting to update the source: winget". Tested this on a managed device, and an unmanaged personal device and got the same results. Tried a source update / reset and still the same issue. Happy to hear it's not just my environment.

Answer 7 · 2025-10-28T03:13:14.000Z

I just got the same result regarding "Our services...".

Note: If you get "The request is blocked." that's a different issue related to a cookie and can be mitigated by using a private browser session.

Answer 8 · 2025-10-28T03:42:25.000Z

This appears to be an upstream issue with our CDN provider. We have engineers engaged to investigate.

Answer 9 · 2025-10-28T03:44:50.000Z

Related to:

#5835

Answer 10 · 2025-10-28T03:48:28.000Z

ha... I tried some winget commands for the past 1 hour or so and was getting errors or it was not completing at all... :\

An unexpected error occurred while executing the command:
InternetOpenUrl() failed.
0x80072ee2 : unknown error

... now it's back:

Answer 11 · 2025-10-28T03:59:31.000Z

Because outages have a way of exposing oversights in underlying architecture (and because this one has taken enough of my day that a few extra minutes on GitHub won't break the bank 😉):

Maybe I've just been spoiled by the likes of pacman, but I would have thought assets like these .msix files would be static and therefore relatively impervious to outages? Not that hosts serving static files never go down (robust as one would hope a Microsoft-backed CDN would be), but in winget's case, an outage that, say, takes out the build pipeline responsible for these files--problematic as it would be--wouldn't leave users with a completely useless CLI until fixed. Most of us would carry on without noticing the source data getting a bit stale, given it really is just a metadata repository.

The fact that the endpoint is slowly returning HTTP 500 errors seems consistent with dynamic servicing of each request--mandatory telemetry perhaps? Or some sort of real-time transform? Is there something happening there that could be disabled to improve the robustness of the platform?

Or maybe--hopefully!--I'm wrong, the assets are already completely static, and this is "just" a catastrophic CDN failure.

(No criticism is intended here, BTW -- I've only recently had to patch one of my own deployments because of a regression that didn't show up in testing, so this isn't coming from any sort of high ground or judgement! Just thoughts based on observations, albeit in the context of the same frustration we all share with the outage.)

Answer 12 · 2025-10-28T04:11:10.000Z

Meanwhile, it would appear your upstream provider has restored service because everything just started working again. Thank you!

(And from a quick look at the HTTP headers, it seems I was wrong and these are indeed completely static assets. So that just leaves tuning headers to allow them to get a bit stale and/or giving winget permission to proceed with a stale source if it can't refresh it.)

Answer 13 · 2025-10-28T05:17:51.000Z

for me in Germany it works now fine.

Answer 14 · 2025-10-28T05:20:56.000Z

Still not working

Answer 15 · 2025-10-28T15:15:20.000Z

I can confirm it is also working fine for me now in Virginia, US.

Answer 16 · 2025-10-28T17:46:40.000Z

This is still ongoing on my end for about 16+ hours now... Asia-Pacific region.

Time out on cdn.winget.microsoft.com, but storeedgefd.dsx.mp.microsoft.com seems to be responsive.

Answer 17 · 2025-10-28T17:55:59.000Z

as said, for me it works now in Europe:

Answer 18 · 2025-10-28T19:44:40.000Z

This is still ongoing on my end for about 16+ hours now... Asia-Pacific region.

Time out on cdn.winget.microsoft.com, but storeedgefd.dsx.mp.microsoft.com seems to be responsive.

It's now working on my end, Asia-Pacific region. 👍

Answer 19 · 2025-10-28T20:01:15.000Z

@lkrms we have been discussing the logic used on a retry and the best way to proceed if we can't fetch an updated cache. In one case if we're not able to get the "initial" cache, it would be a complete failure. In the event of a stale cache we could proceed with that stale cache and some kind of informational message about how old the cache is.

Answer 20 · 2025-10-28T23:58:18.000Z

Working for me now.
PS C:\> winget source update --logs
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
Done
Note: --logs opens winget logs directory in file explorer.

Also note, don't bother with pinging hostname, by design it will not reply. If you want to check connectivity, outside of using winget command, try testing with curl instead.
example:
PS C:\> curl.exe -v -s https://cdn.winget.microsoft.com/cache/source.msix -o NUL
PS C:\> curl.exe -v -s https://cdn.winget.microsoft.com/cache/source2.msix -o NUL

Look for 'HTTP/1.1 200 OK' in response.

Answer 21 · 2025-10-29T12:43:06.000Z

@lkrms we have been discussing the logic used on a retry and the best way to proceed if we can't fetch an updated cache. In one case if we're not able to get the "initial" cache, it would be a complete failure. In the event of a stale cache we could proceed with that stale cache and some kind of informational message about how old the cache is.

It makes sense for winget to keep its cache in sync transparently; I'm coming at it from a Linux package management angle (I've already mentioned pacman, but apt and others are similar), where in the absence of optional tooling, the cache isn't refreshed from upstream unless you explicitly request it.

I'm not suggesting winget should do likewise--it's a different beast with a different audience--but the case for allowing users to "sync" and "install" as distinct operations if they choose to is arguably stronger for winget than for a typical Linux package manager, simply because its cache is, by definition, decoupled from the hosting platform of basically every package it services.

If I can't sync my pacman cache, I can't install packages either, because they all come from the same place; but winget doesn't suffer from this constraint 🙂. Its default behaviour when the cache is unreachable is important to get right, especially when you factor in bootstrapping scenarios, but perhaps it could be left as-is, albeit with improvements to how the failure is communicated to end-users. If a --no-sync option (and/or a no-implicit-cache-sync setting) were available, it could be suggested as a way to mitigate the issue temporarily, for example. And for users who would always enable --no-sync, I guess you'd need a standalone sync command. Best of both worlds?

Answer 22 · 2025-10-29T16:52:25.000Z

Not working for me as well.
http://cdn.winget.microsoft.com/ is not working.
https://storeedgefd.dsx.mp.microsoft.com/ is responding.

Answer 23 · 2025-10-29T18:41:43.000Z

Same error here.
Are there any updates on this?

Answer 24 · 2025-10-29T20:44:52.000Z

Connectivity to cdn.winget.microsoft.com just restored for me, after latest azure front door outage, refer https://azure.status.microsoft/status.

PS C:\> nslookup -type=a cdn.winget.microsoft.com. ns4
  
Non-authoritative answer:
Name:    akl21r9a.msedge.net
Address:  104.212.68.148
Aliases:  cdn.winget.microsoft.com
          winget-cache-pme-cxfsgwfxarb8hwg0.z01.azurefd.net
          mr-z01.tm-azurefd.net
          shed.dual-low.part-0010.t-0009.t-msedge.net
          azurefd-t-fb-prod.trafficmanager.net
          dual.part-0003.t-0009.fb-t-msedge.net
          global-entry-fb-afdthirdparty-unicast.trafficmanager.net
  
PS C:\> winget source update --verbose
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
Done
Updating source: winget-font...
Done

Answer 25 · 2025-10-29T20:56:01.000Z

I'm going to go ahead and close this as a duplicate of #5835

#5835

I do realize the distinction that this was reported due to a CDN issue impacting WinGet, and the most recent issue was related to Azure Front Door, but I want to keep the number of issues down to avoid having to go hunt all the duplicates down to close them.