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

why the bug issue is closed without fixing it? clean installing windows os isn’t a reasonable solution.

Can you run that command with --verbose-logs and post the log file?

Also: does winget source reset --force fix it? I kind of doubt it, but it seems to be able to recover from other weirdness.

winget source update --name winget gets me

tried all methods. It seems most of the servers are down. msstore working fine.

💡Workaround/manual fix is point cdn.winget.microsoft.com to a cache IP with a still working source.msix file (152.195.19.97): 1 - Open C:\Windows\System32\drivers\etc\hosts with a text editor as administrator (e.g., Notepad/VS Code). 2 - Add it to the end of the file: 152.195.19.97 cdn.winget.microsoft.com 3 - Save the file. 4 - Run it as administrator: winget source reset --force

All, we had a couple of pesky nodes and had to get our CDN provider to flush them. We’ve also deployed changes to include a purge after each publish run at about 5:00 PM Pacific yesterday. We’re keeping an eye on any further reports of the zero-byte file being served.

Thank you for all the reports with IP addresses. These have been very helpful for us to track down the offending endpoints.

Considering the fact that this issue seems to be isolated to EU (and perhaps other regions), but US and Japan areoperational, I have a temporary workaround.

Use this to find an IP address from US, then add a line in your hosts file (%WINDIR%\System32\drivers\etc\hosts). For example, this is what I added

152.195.19.95 cdn.winget.microsoft.com

After this, run winget source update and it should properly update.

UPDATE:

Well, that worked once, but now it seems all IP addresses are returning the same result. My guess is they’re all down for “maintenance” 😄

I concur:

I’m in the UK, and also getting:

$ winget search VisualStudio
Failed in attempting to update the source: winget

Downloading https://cdn.winget.microsoft.com/cache/source.msix results in a 0 byte file.

Just hit this issue, and the folks above with the temporary host entry solution got it right. They are having CDN issues (image below), except the ip that worked for me is the following:

152.199.52.147 cdn.winget.microsoft.com

For the people dropping by:

winget source reset --force
winget upgrade

And chose ‘Y’ if you agree to the terms.

Just for completeness, I also tried to WSReset.exe and a forEach PowerShell snippet to restore the default Windows Appx packages. None worked.

So I ended up by doing a clean install (and of course it’s working now).

Lesson taken: never make registry changes without a backup.

Also having the same issue… Going and manually downloading/installing from https://cdn.winget.microsoft.com/cache/source.msix seems to update the source (New updates are available afterwards with winget update) But running winget source update --name winget still gets me Cancelled error

One interesting thing to note is that https://cdn.winget.microsoft.com/cache/source.msix sometimes seems unavailable, I have to try ~2-3 times to download it.

This works for me as a temporary fix for now. Steps:

• %TEMP%\WinGet - Folder Deleted
• Going and manually downloading/installing from https://cdn.winget.microsoft.com/cache/source.msix
• winget source reset --force
• winget source update
• winget upgrade --all

For me, simpler fix: winget source update from elevated command prompt.

Non elevated had this:

PS 7.3 C:\Windows\System32 0 $ winget upgrade
Failed in attempting to update the source: winget
Name                                        Id                             Version      Available   Source
----------------------------------------------------------------------------------------------------------
[redacted]
PS 7.3 C:\Windows\System32 0 $ winget source update
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
Cancelled

Elevated:

PS 7.3 C:\Windows\System32 0 # winget source update
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
  ██████████████████████████████  100%
Done
PS 7.3 C:\Windows\System32 0 # winget update
Name                                                               Id                             Version        Available     Source
[redacted]

Non elevated prompt, after elevated source update (no “failed in attempting to update the source” line):

PS 7.3 C:\Windows\System32 0 $ winget upgrade --all
Name                                                               Id                             Version        Available     Source
[redacted]

Issue is still persistent: winget source update Updating all sources… Updating source: msstore… Done Updating source: winget… Cancelled

Ah I see what you mean.

It saves a few temporary files to C:\Windows\Temp but the actual source file is saved to C:\Users\%USERNAME%\AppData\Local\Temp\WinGet and then provisioned via Add-AppxPackage.

I’m not sure what exactly is wrong with your system, but winget is failing to deploy the latest source file. Here are some things that might help you recover:

1. Reset the source package [instructions for Win11 as it is in front of me, shouldn’t be too different for Win10] a. Go to Settings (🪟 + i ) > Apps > Installed Apps b. Search for Windows Package Manager Source (winget) c. Click the 3 dots on the right > Advanced Options d. Reset the package (you could try Repair but Reset is a bigger hammer and there is no data to lose) e. This will attempt to re-register the package with the system and hopefully make things happy again.
2. Remove the winget source package a. If you tried the above and it didn’t work, just use the Uninstall right there. b. Or winget source remove winget a. This will attempt to actually remove the existing source package from your system.

I agree that there is potentially something that we could do here to recover in a more automated fashion, although it would most likely be automating the removal to hopefully enable a new installation to just work. If that doesn’t do it we would probably need to understand what was actually wrong to be able to mitigate.

Since yesterday I am having this issue too…

winget source update，no effect winget source reset --force，no effect

download and install https://cdn.winget.microsoft.com/cache/source.msix still has no effect

@MadSpindel

• Close any PS window
• Delete the folder C:\Users\%USERNAME%\AppData\Local\Temp\WinGet
• Open new PS window (as admin)
• Run the following --> winget source update
• Enjoy winget

(Kudos to @biyiklioglu for the solution)

I recently ran into this error message after installing WingetUI. If installed, your attempt to run winget from shell may collide with a sub-process of winget under an active WingetUI instance.

Exit one of the instances, such as WingetUI to avoid this message in shell…and likely vice-versa.

We’re working to renew the certificate:

• https://github.com/microsoft/winget-cli/issues/2956

same issue

I closed the issue because in my case, other parts of Windows (apart from Winget) were also broken as mentioned here. Is it your case as well?

I just managed to fix this by installing the pre-release from https://github.com/microsoft/winget-cli/releases

Ok, so for everyone who is here right now, having the exact same issue as everyone else, read the pinned issue #3652 😄

Also having the same issue… Going and manually downloading/installing from https://cdn.winget.microsoft.com/cache/source.msix seems to update the source (New updates are available afterwards with winget update) But running winget source update --name winget still gets me Cancelled error

One interesting thing to note is that https://cdn.winget.microsoft.com/cache/source.msix sometimes seems unavailable, I have to try ~2-3 times to download it.

I also think this is a problem with the upstream repository, as this appears to have started sometime yesterday for everybody at around the same time that the App Installer package was updated. The error is happening to me somewhat randomly; currently it’s working if I run winget upgrade, but some of the admin commands are still failing with the “Cancelled” error.

If you have tried all the suggestions on this issue and still could not solve the problem your issue could be caused due to wrong permissions on the winget installer download directory.

Symptoms:

• Running winget update with nonadmin user fails with Failed in attempting to update the source: winget
• Running winget source update --name winget with nonadmin user fails with Cancelled
• winget update works fine with admin user

Cause:

Nonadmin user has no permissions to the winget installer download directory:

%TEMP%\WinGet = C:\Users\%USERNAME%\AppData\Local\Temp\WinGet

May be related to #3322

Solution:

Correct the permissions on the %TEMP%\WinGet directory or simply delete it so it would be recreated.

All, we had a couple of pesky nodes and had to get our CDN provider to flush them. We’ve also deployed changes to include a purge after each publish run at about 5:00 PM Pacific yesterday. We’re keeping an eye on any further reports of the zero-byte file being served.

Thank you for all the reports with IP addresses. These have been very helpful for us to track down the offending endpoints.

Thanks for the update.

Glad to help!

💡Workaround/manual fix is point cdn.winget.microsoft.com to a cache IP with a still working source.msix file (152.195.19.97): 1 - Open C:\Windows\System32\drivers\etc\hosts with a text editor as administrator (e.g., Notepad/VS Code). 2 - Add it to the end of the file: 152.195.19.97 cdn.winget.microsoft.com 3 - Save the file. 4 - Run it as administrator: winget source reset --force

I’m getting a 0 byte file from 152.195.19.97 as well:

❯ curl -v https://cdn.winget.microsoft.com/cache/source.msix
*   Trying 152.195.19.97:443...
* Connected to cdn.winget.microsoft.com (152.195.19.97) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* ALPN: server accepted http/1.1
> GET /cache/source.msix HTTP/1.1
> Host: cdn.winget.microsoft.com
> User-Agent: curl/7.83.1
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Age: 4783
< Content-MD5: 8/Hlw4nUixEpIij+LGbFaw==
< Content-Type: application/octet-stream
< Date: Mon, 28 Nov 2022 16:42:44 GMT
< Etag: 0x8DAD1546FAE2431
< Last-Modified: Mon, 28 Nov 2022 15:23:00 GMT
< Server: ECAcc (dcd/7D12)
< X-Cache: HIT
< x-ms-blob-type: BlockBlob
< x-ms-lease-status: unlocked
< x-ms-meta-da7b2905_0f3c_4262_921c_b1593d1336f1_ESRP_RequestId: d2e84923-cabd-42e9-947b-21992278156d
< x-ms-request-id: 2497b7b6-401e-005e-553d-035a64000000
< x-ms-version: 2009-09-19
< Content-Length: 0
<
* Connection #0 to host cdn.winget.microsoft.com left intact

re: sba923. The difference I noticed in your two images is the one that worked used ipv4, the broken one used ipv6. So I tried disabling ipv6 on my network adapter, and bingo, “winget source update” worked. Then re-enabled ipv6 and the “winget upgrade” was OK too - for a while, then started giving the “Failed in attempting to update the source: winget” warning again. Probably when the domain resolved to the ipv6 address again. So I THINK at least part of the issue is problems getting to their CDN over ipv6.

UPDATE: Windows 10 22H2 | PowerShell 7.3.0 | Location: France

Problem gone

Same issue here in Hungary. It’s just popped up since a few days ago.

Same issue, Vietnam.

Same issue, Eastern Coast USA

Guys, just in case you don’t know and you really depend on winget for whatever reason: you can manually clone the winget-pkgs repository and use winget install -m path/to/manifest/folder you want to install.

I can confirm that nothing works in Europe. I even added US IP but it didn’t change anything. Maybe a VPN works.

I turned on VPN and winget upgrade and winget source reset --force executed successfully. I tried a US and Japanese IP, both worked.

Did you guys make some changes to C:\Windows\Temp folder ?

Running winget source update --name winget on your device will download the winget source file to C:\Users\%USERNAME%\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix and not to C:\Windows\Temp.

If you’re having issues deploying the latest source file, it’s likely an issue on your end; try seeing if you can repair your current installation of Windows by installing Windows on top of your current installation.

Thanks man, it worked for me! I had the same error as OP

I’ve run first: “winget source update --name winget” and then “winget install --id GitHub.cli”

Thanks again.

So, I think in this sense, this bug isn’t much of Winget’s concern but rather Windows itself. As mentioned in https://github.com/microsoft/winget-cli/issues/1656#issuecomment-955080920, perhaps the best would be to report in the Windows Feedback Hub.

Unfortunately, no logs are shown, and the command does not help either.

➜ winget source reset --force
This command requires administrator privileges to execute.

➜ gsudo winget source reset --force
Resetting all sources...Done

➜ winget upgrade
Failed in attempting to update the source: winget
The `msstore` source requires that you view the following agreements before using.
Terms of Transaction: https://aka.ms/microsoft-store-terms-of-transaction
The source requires current machine's geographic region to be sent to function properly.

Do you agree to all the source agreements terms?
[Y] Yes  [N] No: y
No installed package found matching input criteria.
➜ winget upgrade Microsoft.Teams --verbose-logs
Failed in attempting to update the source: winget
No applicable update found.