When I try to manually download the source.msix file from https://cdn.winget.microsoft.com/cache/source.msix this results in a 0kb file. Seems like this may be the problem. The source has no content.

Off topic

Aren’t you all people with a background in IT? There are several pieces of vital information now scattered in a heap of “It doesn’t work on my machine” posts. Please think if you can add something relevant before adding to the queue.

Even if there would be no monitoring for winget’s update sources, GitHub issues are not a good way to “alert the authorities” to fix something. Their purpose is to gather a clear understanding of what’s the issue.

Please contact Microsoft instead if you’re unhappy with their service.

All edge nodes have been reset, affected users may try running winget source update

Hey everyone. We’ve been having a CDN issue. We’re working through it. It’s not affecting all users.

I presume when someone spends “3h doing a clean reinstall of Windows” it may be cathartic to post a comment here, even if it means some maintainer will eventually have to spend an extra few milliseconds scrolling past the comment.

Personally I don’t post “me too” comments, instead choosing to upvote (and hope that maintainers prioritise by upvotes rather than just comment activity). However I don’t find fault with pple who prefer to comment.

Regarding “contact Microsoft instead”

• someone did
  • it’s not very citable (no URL) compared to a GH ticket
• an issue on a public repo (that MS owns) is the primary way many open source devs prefer to make contact, and if MS doesn’t like this it should disable issues

they should kill their X-Cache parameter 🙈 Or allow to refresh by the clients!!! 🙈🙈🙈

Because it is working, if changing the “x” to “%78”: curl -vL https://cdn.winget.microsoft.com/cache/source.msi%78

Output:

*   Trying 152.199.21.175:443...
* Connected to cdn.winget.microsoft.com (152.199.21.175) port 443 (#0)
* schannel: disabled automatic use of client certificate
* ALPN: offers http/1.1
* ALPN: server accepted http/1.1
> GET /cache/source.msi%78 HTTP/1.1
> Host: cdn.winget.microsoft.com
> User-Agent: curl/7.83.1
> Accept: */*
>
* schannel: failed to decrypt data, need more data
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Cache-Control: private, max-age=300
< Content-MD5: xdL0r96zSnxrZmGgwn6Uuw==
< Content-Type: application/octet-stream
< Date: Sun, 06 Nov 2022 18:03:27 GMT
< Etag: 0x8DABF5CD7821DE0
< Last-Modified: Sat, 05 Nov 2022 18:37:49 GMT
< Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
< x-ms-blob-type: BlockBlob
< x-ms-lease-status: unlocked
< x-ms-meta-da7b2905_0f3c_4262_921c_b1593d1336f1_ESRP_RequestId: 604aed43-0258-42de-b26d-ed73b765d3b4
< x-ms-request-id: 68b1dd0a-c01e-000b-160a-f2b113000000
< x-ms-version: 2009-09-19
< Content-Length: 5273087
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failure writing output to destination
* Closing connection 0
* schannel: shutting down SSL/TLS connection with cdn.winget.microsoft.com port 443

cc @ShaguarWKL: You could probably use winget-ppe as a temporary solution. Run winget source add --name winget-ppe --arg https://winget-ppe.azureedge.net/cache

I do want to point out that there are several packages missing from that source; some of them are outdated; and for some of them — you will also likely run into hash errors.

winget-ppe (as well as winget-int and winget-test) is also not meant for production usage. It’s used by WinGet developers for testing purposes only.

It’s recommended to wait until the winget source is back online to ensure you’re downloading the latest software.

should have read that first 😕 I had the same issue this morning followed all the troubleshooting that I can find with no result (close to what https://github.com/microsoft/winget-cli/issues/2666#issuecomment-1303448425 list)

ended up with a clean full reinstall of windows for the same result… damn lost 3 hr of my life

…as other have pointed out, this is because a 0 byte file is being returned by the Azure Content Delivery Network (see RawContentLength : 0 below). It’s not a reachability or client issue.:

PS C:\Users\UserName\Downloads> wget https://cdn.winget.microsoft.com/cache/source.msix


StatusCode        : 200
StatusDescription : OK
Content           : {}
RawContent        : HTTP/1.1 200 OK
                    Age: 60672
                    Content-MD5: fDzGv2IMVnqEbTVA5MDliA==
                    X-Cache: HIT
                    x-ms-blob-type: BlockBlob
                    x-ms-lease-status: unlocked
                    x-ms-meta-da7b2905_0f3c_4262_921c_b1593d1336f1_ESRP_RequestId:...
Headers           : {[Age, 60672], [Content-MD5, fDzGv2IMVnqEbTVA5MDliA==], [X-Cache, HIT], [x-ms-blob-type,
                    BlockBlob]...}
RawContentLength  : 0

winget.azureedge.net is a CNAME for cdn.winget.microsoft.com, results are the same.

Considering it’s weekend and nobody from the team responded here yet we can assume they don’t know about it? Maybe a rude Sunday ping will get some attention, @denelon sorry but this is a showstopper. ☹

This worked yesterday, from a previous comment.

IP address: 152.199.52.147 Location: Sao Paulo, Brazil

Yesterday, at the start of a new block, I started class with “You don’t have to worry losing time over installation or configuration issues, we won’t be using your personal laptops but only school computers. When you log in to your school account you’ll see an icon on the desktop. Double-click that and it’ll install all necessary software. We’ve tested that extensively. You’ll be up and running in no time.” That was fun.

Fixed, though shouldn’t there be mirrors or some other mitigation for downtime? I had this linked to some scripts for updating and installing software on my machines, but I could only imagine the havoc this would wreck if it were used in any enterprise setting.

Same issue in the UK

Same issue here in Europe too.

Same here. I tried every recommendation for this issue but had no luck. I can’t even get verbose logs.

> winget upgrade --verbose-logs
Failed in attempting to update the source: winget
Failed when searching source; results will not be included: winget
No installed package found matching input criteria.

Temporary Fix: I used US VPN and it worked. It might be winget server issue I have no idea.

Hello everyone.

We’ve made several changes to our deployments to address the problems here. There were some changes to the way we publish to Azure storage, and permissions on some of the files as well as the CDN configuration. We believe this has all been mitigated with respect to the zero-byte file.

We’re still tracking:

• https://github.com/microsoft/winget-pkgs/issues/86160

We switched temporarily to a manual CDN purge for a couple of days while we worked through the issue. We have also added the ability to purge the CDN with each publish run, but the code is behind a feature toggle and is currently disabled. If we need to resort to that in the future, it will cause a few minutes of delay for each publish run, but it’s available in the event we need it.

I’m going to go ahead and close this issue due to the number of people following this and getting e-mail notifications. If you are still encountering trouble, please create a new issue, or find one that appears to be the same so we can try to help with those other classes of issues.

The issue is resolved.

Already has for us; we use it for post staging after our imaging process. We chose to keep a backup sources.msix and to use Add-AppxPackage as a workaround if the issue happens again. Tinkering around with the idea of creating a scheduled task to update the file once a month

It’s working now, thanks.

FYI - https://www.bleepingcomputer.com/news/microsoft/microsoft-winget-package-manager-failing-due-to-cdn-issues/

age, its not designed to be uninstalled. Why are you trying to remove and reinstall it?

Not the smartest question in the world – (A) Because it isn’t working properly! You have to manually install App Installer to get it working in the first place, from the Windows Store of all places. There are many cases where clean re-installs help fix software.

Malice is uncalled for. If you have a issue unrelated to the tool failing to update its source package, please create a separate issue.

age, its not designed to be uninstalled. Why are you trying to remove and reinstall it?

Not the smartest question in the world – (A) Because it isn’t working properly! You have to manually install App Installer to get it working in the first place, from the Windows Store of all places. There are many cases where clean re-installs help fix software.

So, after reading through this thread, this sounds like an actual outage issue/bug with the winget cdn, and not a configuration issue on my system? Is that correct?

What’s the source URL given by winget source list on a working machine?

It should be https://cdn.winget.microsoft.com/cache which is the same as https://winget.azureedge.net/cache

source.msix part is automatically added by winget-cli in the code so you won’t see the source.msix part in winget source list but it’ll show up in your logs.

CDN for the production environment has been having a bunch of issue over the past couple of weeks.

PPE, INT, & TEST doesn’t seem to be affected.

@haxorof It seemed to have worked 2 or so hours ago. Now I am still seeing this issue from Germany. Both on IPv4 and IPv6.

As mentioned earlier a workaround is to use the host file on your local computer to point cdn.winget.microsoft.com at a different cache IP that still has a valid file.

Just until the larger problem is addressed.

Same issue in France

+1: Same issue in Germany. Was still OK last Friday

+1 in Germany. Was already broken for me on friday.

+1: Same issue in Germany. Was still OK last Friday

same issue in Beijing, China

Japan reporting in, issue is still here.

Why is this a thing?

Its a System Package, its not designed to be uninstalled. Why are you trying to remove and reinstall it?

Btw, can anyone tell how to uninstall MSIX-installation and reinstall it in “vanilla” way? 😅

Package App Installer not present in apps list and in msstore install/uninstall button not showing, kek.

KO in France

I’ve raised this up with MS’s support team as well to try and get some more traction on it: Customer Support case ID is 1045919447

Looks like only programatical bugs are really delt with when reported on here.

For ExpressVPN users: “Canada - Vancouver” was what worked for me after many others (including from Canada and US) failed.

works for me.

@TacticalNuclearSpud try using Hotspot Shield, it worked for me on the automatic setting

That worked! Thank you!

Temporary Fix: I used US VPN and it worked. It might be winget server issue I have no idea.

This worked for me from Aus; Set my VPN to Salt Lake City and it worked without a hitch.

Well, at least I know that my system isn’t broken. However, does anyone have an idea of when this issue will be fixed?

+1

Some users reported it as solved, but I still see this issue occur in Europe/Germany. Did I miss the workaround?

PS C:\Users\user> winget --info
Windows Package Manager v1.3.2691
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22621.755
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.18.2691.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

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

I see the same here in Germany today. Still not working. Resolution of cdn.* to IP address is OK, but the upgrade command does not work.

Hi!

Same here: Updating source: winget... Cancelled

Verbose logs:

2022-11-11 07:45:02.338 [CORE] OS: Windows.Desktop v10.0.22621.819
2022-11-11 07:45:02.338 [CORE] Command line Args: winget  source update --verbose-logs
2022-11-11 07:45:02.338 [CORE] Package: Microsoft.DesktopAppInstaller v1.18.2691.0
2022-11-11 07:45:02.338 [CORE] IsCOMCall:0; Caller: winget-cli
2022-11-11 07:45:02.343 [CLI ] WinGet invoked with arguments: 'source' 'update' '--verbose-logs'
2022-11-11 07:45:02.343 [CLI ] Found subcommand: source
2022-11-11 07:45:02.343 [CLI ] Found subcommand: update
2022-11-11 07:45:02.343 [CLI ] Leaf command to execute: root:source:update
2022-11-11 07:45:02.343 [CLI ] Executing command: update
2022-11-11 07:45:02.347 [CORE] Setting action: Get, Type: Secure, Name: user_sources
2022-11-11 07:45:02.358 [CORE] Setting action: Get, Type: Standard, Name: sources_metadata
2022-11-11 07:45:02.359 [YAML] Detected UTF-8
2022-11-11 07:45:02.359 [REPO] GetCurrentSourceRefs: Source named 'microsoft.builtin.desktop.frameworks' from origin Default is hidden and is dropped.
2022-11-11 07:45:02.373 [CORE] Setting action: Get, Type: Secure, Name: user_sources
2022-11-11 07:45:02.373 [CORE] Setting action: Get, Type: Standard, Name: sources_metadata
2022-11-11 07:45:02.373 [YAML] Detected UTF-8
2022-11-11 07:45:02.374 [REPO] Named source requested, found: msstore
2022-11-11 07:45:02.375 [CORE] Setting action: Get, Type: Secure, Name: user_sources
2022-11-11 07:45:02.375 [CORE] Setting action: Get, Type: Standard, Name: sources_metadata
2022-11-11 07:45:02.375 [YAML] Detected UTF-8
2022-11-11 07:45:02.375 [REPO] Named source to be updated, found: msstore
2022-11-11 07:45:02.375 [CORE] Setting action: Set, Type: Standard, Name: sources_metadata
2022-11-11 07:45:02.479 [CORE] Setting action: Get, Type: Secure, Name: user_sources
2022-11-11 07:45:02.479 [CORE] Setting action: Get, Type: Standard, Name: sources_metadata
2022-11-11 07:45:02.479 [YAML] Detected UTF-8
2022-11-11 07:45:02.480 [REPO] Named source requested, found: winget
2022-11-11 07:45:02.481 [CORE] Setting action: Get, Type: Secure, Name: user_sources
2022-11-11 07:45:02.481 [CORE] Setting action: Get, Type: Standard, Name: sources_metadata
2022-11-11 07:45:02.481 [YAML] Detected UTF-8
2022-11-11 07:45:02.481 [REPO] Named source to be updated, found: winget
2022-11-11 07:45:02.670 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(311)\WindowsPackageManager.dll!00007FFE250965C7: (caller: 00007FFE250FF80F) Exception(1) tid(bfc) 8051100F 
2022-11-11 07:45:02.671 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(53)\WindowsPackageManager.dll!00007FFE2520F321: (caller: 00007FFE250F2D1C) LogHr(1) tid(bfc) 8051100F     Msg:[D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(311)\WindowsPackageManager.dll!00007FFE250965C7: (caller: 00007FFE250FF80F) Exception(1) tid(bfc) 8051100F ] 

2022-11-11 07:45:02.671 [REPO] Source add/update failed, waiting a bit and retrying: winget
2022-11-11 07:45:04.723 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(311)\WindowsPackageManager.dll!00007FFE250965C7: (caller: 00007FFE250FF80F) Exception(2) tid(bfc) 8051100F 
2022-11-11 07:45:04.723 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(634)\WindowsPackageManager.dll!00007FFE2520EF51: (caller: 00007FFE2501B8F3) LogHr(2) tid(bfc) 8051100F     Msg:[D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(311)\WindowsPackageManager.dll!00007FFE250965C7: (caller: 00007FFE250FF80F) Exception(2) tid(bfc) 8051100F ] 

2022-11-11 07:45:04.723 [REPO] Failed to update source: winget
2022-11-11 07:45:04.928 [CLI ] Leaf command succeeded: root:source:update```

winget --info displays the log location.

The CDN still has some flakiness issues, it seems; I had to use the “force a different IP” workaround to get things working here just now. Location is US (specifically, central Ohio); IP served was 152.195.19.97. I switched to 152.199.52.147 as suggested above (by way of the new Hosts File Editor in PowerToys; good stuff 😃 ) and that temporarily mitigated the problem.

I just think that, if the DO stuff is unrelated, winget should have worked out-of-the-box on my fresh Windows install. Not require me to apply the same DO stuff/fix again.

It DOES work out of the box. The resolution of the CDN issues was flaky in the beginning: working, not working, working again. So yes, it was just coincidence on your end.

winget source reset --force

Actually worked

I had to close all terminals When I open a new one, winget upgrade worked just fine

Restarting the DO Service

DO = Delivery Optimization Service

E.g.

net stop dosvc
net start dosvc

Skeptical that this solves anything. Since people literally see 0-byte files coming off some cache servers, but other cache server IPs still serve complete files (which should be the actual problem). But maybe Delivery Optimization service sees these 0 bytes files as a signal it needs to switch to another IP (but only after a restart??).

2606:2800:233:1cb7:261b:1f9c:2074:3c now serves a 5MB file again for https://cdn.winget.microsoft.com/cache/source.msix . So Microsoft/EdgeCast is probably fixing their global caching.

Edit: I can confirm that on on KPN.nl network, winget works fine right now. Thanks for fixing the cache, mystery person 😅

Thanks @eggheadedmonkey. I spoke to our dev, I think the DO stuff you did was unrelated. It was probably a timing issue when hackean-msft reset the cache

I’ve added to the customer incident abput it being an issue on the server side with x-cache the manual way of getting the sources file out from server by setting X manually with a command such as curl.

Also nice to know that I can force DNS to point at the above IP address locally to work around the issue, but isn’t likely a viable resolution as I think the bug will be in webserver config somwhere and is will be slowly propergating out. The ones that are still working are probably like that because their config has yet to update, or they have the new config and the new config has failed to propergate to all servers correctly.

The issue isn’t one with winget itself, but with the supporting hosting infrastructurem which is likely why reporting the issue here isn’t actually getting a correct or proper response, its not really an issue for the dev team of winget.

This one works for me: 152.195.19.97. Tested with wget https://cdn.winget.microsoft.com/cache/source.msix

As mentioned earlier just use the host file on your local computer to point cdn.winget.microsoft.com at a different cache IP that still has a valid file. Just so one can get up and running until fix.

Can someone post an IP address that works?

+1 broken in austria

+1 I’m having the same issue in Indonesia.

@DavidTheCashman You can use vpn.

+1, not working in Finland.

Does anyone have some kind of workaround?

+1, not working in HK. same issue

If Vancouver Canada is still working, can anyone provide an IP address for cdn.winget.microsoft.com please? Using this site, I can’t see it. I don’t have any VPN, so I’m going to try this by modifying my hosts file.

UPDATE: I found another one that seems to be working

IP address:     152.199.52.147
Location:       Sao Paulo, Brazil

For ExpressVPN users: “Canada - Vancouver” was what worked for me after many others (including from Canada and US) failed.

I’m in South Africa. Tried VPN to US and Canada. Dint work until I specified Vancouver. Thanks for the post @YorVeX

Same here. ExpressVPN (Miami location) works.

For those that like to integrate winget into powershell scripts; using the VPN workaround to grab the sources.msix file and then installing it using AppxPackage has served as a good workaround for brand new clients to winget. I think I’ll be keeping a copy of source.msix every so often just in case now.

But why is the CDN messed up like this? This is Microsoft we’re talking about here, one would think that they’d have running a CDN down to a science.

@TacticalNuclearSpud try using Hotspot Shield, it worked for me on the automatic setting

One of those issues likely solved by having a long beer.

Alas, I don’t like beer 😦

UK here, switching to Canada VPN allowed me to update the source.

One of those issues likely solved by having a long beer.

Fix:

Edit: winget source reset --force seems to have worked:

It doesn’t work - your output still notes that the winget source is broken. Only the msstore source is working.

There are dozens of related issues on this repo (e.g #2664), not sure how many are duplicates because I’ve seen different error codes in logs.

I have the same issue.

1. all future winget commands now say Failed in attempting to update the source: winget / Failed in attempting to update the source: winget / Failed when searching source: winget / An unexpected error occurred while executing the command: / 0x8a15000f : Data required by the source is missing
   • Tried resetting winget data in Settings > Apps > Installed apps
   • Tried uninstalling winget in Settings > Apps > Installed apps
   • Tried installing different versions from releases
   • btw winget doesn’t appear in Settings > Apps > Installed apps now anymore (but I can still run winget on the CLI, and “App Installer” is installed in the Microsoft Store)
   • Tried deleting %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe (so winget regenerates it)

Questions

Are there some keys in the registry which need correcting? Alternatively, is the source URL wrong? Also, how to install Microsoft.winget.source_8wekyb3d8bbwe (related to #2421)?

> winget source reset --force
> winget source list
Name    Argument
-----------------------------------------------------
msstore https://storeedgefd.dsx.mp.microsoft.com/v9.0
winget  https://cdn.winget.microsoft.com/cache
> winget list
Failed in attempting to update the source: winget
Failed when searching source; results will not be included: winget
...
# does NOT list Microsoft.winget.source_8wekyb3d8bbwe
...