"Failed in attempting to update the source: winget" #3687
Comments
microsoft-github-policy-service
bot
added
the
Needs-Triage
|
We are experiencing the same. |
|
https://cdn.winget.microsoft.com/cache returns 404 for me |
|
My logs show a Forbidden (403): `2023-09-20 14:53:03.329 [CORE] WinGet, version [1.5.2201], activity [{526FE31F-B772-4A4C-8A9B-8CF2DBF7D178}] 2023-09-20 14:53:03.893 [FAIL] WindowsPackageManager.dll!00007FF9D41803E7: LogHr(1) tid(44b0) 80190193 Forbidden (403). 2023-09-20 14:53:03.896 [FAIL] D:\a_work\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(53)\WindowsPackageManager.dll!00007FF9D43BDF66: (caller: 00007FF9D428D827) LogHr(2) tid(44b0) 80190193 Forbidden (403). |
|
It's already dead, our scripts are useless. Done
No clue why this is necessary. Source list remains the same: PS C:> winget source list
|
For my part, I can't even access your link..: |
|
This also happens on a fresh Windows 10 install which I'm currently using. Apparently the problem is not a client issue, rather servers seems to be down at the moment.
|
|
this should probably be closed as a duplicate of #3652 |
In your opinion, should I wait for an "official" person to answer, or should I close it already? |
|
I have the same problem, not helped even to add 152.195.19.97 cdn.winget.microsoft.com
|
#3669 is closed but not solved. This issue should stay open because #3669 is not reopened and #3652 is not solved yet. Lots of people search for the error message but do not know anything about CDNs. BTW: |
|
This issue affected me as well. A brand new Windows 11 installation didn't help.
This seems to have fixed the issue for me. Thanks! |
|
All I get is: |
Most important note! |
I did it with Edge |
|
I also encountered this issue, but retrying a Key error from the log (v1.6.2631) |
|
Same issue here:
|
|
Come on guys, how can a package manager be down for so long. Don't you have some mirrors? Location: Germany
|
|
Same here. Location: Argentina |
This seems to fix the issue. But why though? |
Not working for me either. Location: Uruguay. |
|
Same issue here and I was really hoping to use winget to update multiple offsite clients. |
|
Same issue here: 2023-09-27 11:07:13.468 [FAIL] D:\a_work\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(313)\WindowsPackageManager.dll!00007FFAE4C41415: (caller: 00007FFAE4DA66AF) Exception(2) tid(d6c) 8051100F 2023-09-27 11:07:13.468 [FAIL] D:\a_work\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(66)\WindowsPackageManager.dll!00007FFAE4DA6745: (caller: 00007FFAE4DA2907) Exception(3) tid(d6c) 8051100F This has happened since I updated to build 22621.2361 released yesterday and after deleting Windows Dev Home and its dependencies such as Windows App Runtime.
It seemed like this didn't fix my problem, but after a reboot everything works fine. |
Tried the fix, was able to download and install. Worked for a few min then the errors came back. |
|
Hey all, we're clearly experiencing CDN issues. We have been working to retire the original CDN due to other challenges with certificate rotation from the past. We have several folks on-call actively working on this. |
|
Related to: |
denelon
added
Issue-Bug
|
This issue is back. How the heck does this issue keep coming back to haunt us? |
|
same issue for me |
|
I too get the issue. Ran source update --verbose-log and posting result here. Replaced real username with |
It looks like the issue is back. At least for devices/users located in India. |
|
it works fine when i updated winget to v1.6.2771 manually |
|
Can confirm, manually updating to 1.6.2771 using the msixbundle solved the issue. The winget source URL stays the same. |
|
For a couple of weeks ago we experienced the exact problem and by that time we used However, last Friday (October 6th) I tried Why does this happen? Even though we tries and want to upgrade Winget regularly, we are an enterprise within financing sector so such breaking changes are not acceptable. Note: msstore is blocked for us. |
|
Same issue for me. I check my connection to so the workaround it works. But I want solution for this issue |
|
I had this issue until I realized I had installed winget via scoop. Once I did |
|
After updating App Installer from MS Store, everything works fine now |
No idea why but I was apparently in the same situation, working fine now after updating via scoop. Good lord, thank you for saving me from this issue lol. |
|
FWIW, here's my current workaround: # Update-WinGetSources.ps1
#requires -RunAsAdministrator
winget source reset --force
$msix = Join-Path -Path $env:TEMP -ChildPath 'source.msix'
Invoke-WebRequest https://cdn.winget.microsoft.com/cache/source.msix -OutFile $msix
Add-AppXPackage -Path $msix
Remove-Item -Path $msix
winget source update |
|
@sba923 your script worked... thanks! 
Now there's version 7.3.9 but winget doesn't have it yet... :D 
|
|
I know I have been battling this one as well, but I am not sure its an actual CDN issue. I see the same We use a proxy for access to the Internet and I can catch every Internet transaction. I can see calls to cdn.winget.microsoft.com which has a status of 200 and then it hits winget.azureedge.net which also is a 200. I am not seeing any 403s in the proxy log itself. My current belief is there is a GPO in the environment that is blocking access and returning a 403 from the SDK call. We don't use the ADMX for Package Manager so I am trying to figure out what GPO it could be. We are a SUS environment though and since the deprecation of Store for Business we have had a lot of flakiness in winget both in Store and in community registry because of Store and WindowsUpdate GPOs. And as a note... the My workaround has been to have folks use posh to pre-cache the Source appx so they can do an install, but that isn't ideal. It also seem to show that the path IWR goes through the SDK does not seem to trigger this block. It works, but it is far from ideal. I would like to figure out what GPO might be influencing this, but once it hits the HttpClient interface things go black box. When using the manually update Source you get the following as well |
|
For anyone still having trouble, I'd recommend installing the Winget preview version which solved this problem on my end: Install winget preview version [Developers Only] After I downloaded and installed the file Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle, I launched a new Terminal session and got this result. The error is gone. 
|
|
Hopefully that actually fixes it. Mine has been fine again for a while but man was it an annoying issue. |
|
Try the below: delete %TEMP%\WinGet winget source update winget upgrade --all |
This actually worked for me. I didn't care to find and restart the App Installer process, so I just rebooted the PC instead. Now it works without issue for me. Thank you. |
|
When I had this problem, the Microsoft Store was also inaccessible.
|
|
Some folks here (especially the ones that get a The only thing that worked for me (and I suspect will work for lots of people): use a VPN to another region, as mentioned in #1826 (comment) These regional CDN issues rarely get resolved quickly because "works for me" for most Microsoft employees. |
|
I had tried quite a few things as well, but was not having any luck resolving the issue. I finally hit the update by @clong365 and confirmed that TLS 1.0 and 1.1 were disabled on my system. Re-enabled those both and it worked. Seems to be working even after I turn them back off as well? Unsure how it originally was broken, so can't do much more testing, but it is working again for me for now. |
|
I found that my problem is gone if turn-on Cloudfare WARP 1.1.1.1 |
This works for me. |
|
Had the same issue, in my case it was solved by setting the Client License Service (ClipSVC) from disabled to manual via regedit. I assume when reinstalling via MS Store the start type of the service will be set to the default value again. |
I downloaded the file onto my laptop with firefox running on Debian, transferred it to my windows machine with sftp, and it still worked. I had to run the file manually from the windows machine, since I couldn't figure out how to run the installer from the shell. |
Many thanks, it works for me. I'm also from Vietnam, and this issue is troublesome because it is related to regional... |
|
This helped for me: |
|
I found a fix using:
Found here: https://www.elevenforum.com/t/failed-in-attempting-to-update-the-source-winget.10288/post-225692 |
and others
Brief description of your issue
Since yesterday evening (around 5pm - UTC+2), I've been getting the error
Failed in attempting to update the source: wingetwhenever I try a command likewinget upgrade.Steps to reproduce
Run
winget upgrade.Expected behavior
That the winget source works.
Actual behavior
Failed in attempting to update the source: wingetCurrent Location: Dunkerque, France
The problem doesn't seem to be present on my computers in Arlon, Belgium or Capellen, Luxembourg.
Logs:
Environment
The text was updated successfully, but these errors were encountered: