winget-cli: Failed in attempting to update the source: winget

The CDN is down again (https://cdn.winget.microsoft.com/cache).

winget source list

Now winget won’t retrieve updates at all. It’s pretty much useless now.

Is no one else experiencing this?

I managed to resolve “Failed in attempting to update the source: winget” with solution provided at the following link: https://github.com/microsoft/winget-cli/issues/1999#issuecomment-1127497598

Which basically says:

I was having the same problem recently. I deleted the “installed.db” file and solved the problem. The location of the file “installed.db”: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\StoreEdgeFD

and then I ran winget source update --verbose-logs

Which seems to have managed to successfully update winget sources.

The solution in my case was to updating the package installer from Microsoft (App-Installer)

Out of the box Windows 11 23H2 (fresh install using ISO from Microsoft) results in a broken winget install. Windows Store installs a bunch of unwanted garbage on the first access to the internet, but apparently App Installer needs to be upgraded manually.

A bit of a shame that this doesn’t work out of the box, nor the sort of error message that end-users can manage to solve themselves, at a minimum the error message could be more useful.

Manually downloading and installing from here got me working: https://winget.azureedge.net/cache/source.msix

Ok solution for me was:

• Open the Microsoft Store
• Click Library
• Scroll through and find App Installer
• Double click App Installer
• It opens the apps page and interestingly enough the “open” or “install/update” button was not there for a second
• A second later it started to download/update but it said there was an error
• I clicked “details” and it basically said it couldn’t update while the app was open.
• I closed the micrsoft store and terminal windows
• I reopened microsoft store
• clicked library
• Now at the top it shows App Installer and says there is an update available.
• Click the update button.
• It will drop down into the list with the rest of the apps and say it was updated moments ago.
• open terminal again and try winget command and it works now.

The only thing that worked for me (and I suspect will work for lots of people): use a VPN to the US region, as mentioned in https://github.com/microsoft/winget-cli/issues/1826#issuecomment-1305894692

These regional CDN issues rarely get resolved quickly because “works for me” for most Microsoft employees.

CDN is down here as well.

Something’s definitely broken with winget recently… getting this error now on multiple PCs in my org when we didn’t used to (including my own when running from an elevated PowerShell terminal). Not sure I have much else to add to this ticket besides “me too”.

The original issue here was reported with WinGet 1.2.

We’ve had multiple CDN changes since then. There have been changes to DNS entries as well as CDN providers. The issues related to the CDN tend to be transient or related to earlier versions of WinGet. We do have monitoring in place for the CDN endpoints, and as soon as an outage is detected, we purge the endpoint and publish an updated version of the source.msix package containing the PreIndexed database of available packages.

The most common issues with the CDN itself are related to a zero-byte index, and older versions of the client. Please ensure you’re running the latest stable version (or a newer preview) of the WinGet client (or Microsoft.WinGet.Client PowerShell module).

If the network address is blocked or not available by policy access to the community repository may not work.

You can test by attempting to download and install the latest PreIndexed package via: https://cdn.winget.microsoft.com/cache/source.msix

We’ve also seen some cases where the default downloader “DO” (Delivery Optimization) may not function due to policy, and it may be possible to resolve by changing the WinGet settings to use “wininet” rather than DO.

I had the same problem on two devices. The solution in my case was to updating the package installer from Microsoft (App-Installer) at https://www.microsoft.com/p/app-installer/9nblggh4nns1. Then all of a sudden the problems were gone.
I suspect that the solution above by @tsull360 goes in the same direction.

Interestingly, for me, I no longer have to use the VPN, after months of having to use a VPN.

It seems to me Microsoft needs to put in place a system to test all their regions continuously.

Manually downloading and installing from here got me working: https://winget.azureedge.net/cache/source.msix

Here too!

Same issue here (see attached)

I’m having this issue as well, I did notice if I VPN out the issue is resolved. I’m using OPNSense as a firewall, but I’m not sure that it’s blocking anything either.

I’m getting this exact behaviour when I try to run this command through powershell remoting (or winrm).

cc @horihel: If you’re using the .msixbundle file then it’s not a supported scenario due to MSIX’s limitations. I believe the MSIX engineering team is tracking this issue but it’s on their backlog for now.

If you want to use WinGet through WinRM then you’ll need to run WinGet unpackaged. You can do this by extracting the contents of the AppInstaller_X64.msix file to your chosen location and run it via winget.exe. You will also have to do this if you want to run WinGet as SYSTEM context.

^ Note: It’s been a while I’ve played around with WinGet through WinRM but lots of people have managed to get it up and running in previous releases of WinGet unless there was something that was changed in the recent releases of WinGet.