Can't upgrade or install packages

[github-account1111]

Since #2666 was closed, and anyone still encountering trouble was asked to create a new issue, I'll reference #2666 (comment) here.

The winget settings file is empty:

{
    "$schema": "https://aka.ms/winget-settings.schema.json",

    // For documentation on these settings, see: https://aka.ms/winget-settings
    // "source": {
    //    "autoUpdateIntervalInMinutes": 5
    // },
}

DO may have policies affecting the behavior of WinGet. If you run winget --info any policies will be displayed associated with WinGet (App Installer).

Would they just be output into console if such policies exist?
I don't see anything out of the ordinary:

> winget --info
Windows Package Manager (Preview) v1.4.2161-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19044.2130
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.2161.0

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

winget source update --verbose-logs
winget upgrade --all --verbose-logs
winget upgrade --verbose-logs

Originally posted by @github-account1111 in #2666 (comment)

[denelon]

I set a couple of policies for the example below:

winget --info
Windows Package Manager (Preview) v1.4.3132-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.25246.1000
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.3132.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

Group Policy                                      State
----------------------------------------------------------
Enable Windows App Installer Local Manifest Files Disabled
Enable Windows App Installer Hash Override        Disabled

[denelon]

You could try changing the default network downloader setting to "wininet":

https://learn.microsoft.com/windows/package-manager/winget/settings#network-settings

[github-account1111]

No, my settings now look like this, but nothing seems to have changed:

{
    "$schema": "https://aka.ms/winget-settings.schema.json",
    "network": {
        "downloader": "wininet"
    }
    // For documentation on these settings, see: https://aka.ms/winget-settings
    // "source": {
    //    "autoUpdateIntervalInMinutes": 5
    // },
}

I also don't get any output past "Links" in winget --info.

[denelon]

@github-account1111 then there aren't any "App Installer" policies affecting WinGet itself. There still may be other networking policies that are affecting overall communications, and I've seen examples of DO policies affecting WinGet.

Can you run winget source reset --force --verbose-logs and share the logs so we can troubleshoot?

The log location is available via winget --info.

If that succeeds, then you should have the current "winget" PreIndexed package cache on your local machine and can try installing or upgrading a package. Be sure to add "--verbose-logs" so we can see what's happening.

[github-account1111]

2022-11-15 18:52:34.983 [CORE] WinGet, version [1.4.2161-preview], activity [{7A702FE2-5F33-4524-8126-052F532FE52F}]
2022-11-15 18:52:34.983 [CORE] OS: Windows.Desktop v10.0.19044.2251
2022-11-15 18:52:34.983 [CORE] Command line Args: "C:\Users\al\AppData\Local\Microsoft\WindowsApps\winget.exe" source reset --force --verbose-logs
2022-11-15 18:52:34.983 [CORE] Package: Microsoft.DesktopAppInstaller v1.19.2161.0
2022-11-15 18:52:34.983 [CORE] IsCOMCall:0; Caller: winget-cli
2022-11-15 18:52:34.989 [CLI ] WinGet invoked with arguments: 'source' 'reset' '--force' '--verbose-logs'
2022-11-15 18:52:34.990 [CLI ] Found subcommand: source
2022-11-15 18:52:34.990 [CLI ] Found subcommand: reset
2022-11-15 18:52:34.990 [CLI ] Leaf command to execute: root:source:reset
2022-11-15 18:52:34.990 [CLI ] Executing command: reset
2022-11-15 18:52:35.014 [CORE] Setting action: Remove, Type: Secure, Name: user_sources
2022-11-15 18:52:35.017 [CORE] Setting action: Remove, Type: Standard, Name: sources_metadata
2022-11-15 18:52:35.017 [CLI ] Leaf command succeeded: root:source:reset

That's a lot shorter than I expected.

After accepting the agreements, I'm back to square one (no updates, packages available for install are all outdated):

[WinkelCode]

Greetings everyone, it looks like the CDN issue has returned, everything worked fine yesterday, now I am seeing the dreaded Failed in attempting to update the source: winget error again, didn't make any changes to networking or WinGet itself.

[oroehrer]

I do have the same problem. Via VPN and Vancouver it works fine, but not directly here from germany.

[LeMapper]

Repository not available

The problem seems to be that the WinGet-Repository is not available atm:

winget source list
Name    Argument
msstore https://storeedgefd.dsx.mp.microsoft.com/v9.0
winget  https://cdn.winget.microsoft.com/cache

https://cdn.winget.microsoft.com/cache
<Error> <script/> <Code>ResourceNotFound</Code> <Message>The specified resource does not exist. RequestId:9d406b90-101e-0009-3aad-f9b3e9000000 Time:2022-11-16T11:18:54.9332556Z</Message> </Error>

[denelon]

That URL is the base for what is actually downloaded. The client will request "source.msix" at that path.

https://cdn.winget.microsoft.com/cache/source.msix

[LeMapper]

@denelon: Thank you for clarifying the URL.
The file downloads with a filesize of 0KB

and cannot be parsed by the app installer:

[denelon]

😔 Yep that's the zero-byte file problem.

[WegnerDan]

Is there anything you can do locally to fix this or is this a strictly CDN-side issue?

[denelon]

This problem is related to the CDN issue. We've made several changes in the configuration to avoid this from happening. We're looking into this. I've seen some users have modified their hosts file to temporarily point to another endpoint that is working correctly. I don't know the list of IP addresses as they are managed by the CDN. With a valid URL it's possible to download and manually install the source.msix file to get a valid copy of the cache. What I can't guarantee is that when the TTL expires (default 5 minutes) it won't repro.

We're going to purge again to see if that will clear the endpoints with the zero-byte file.

[engiecat]

Hi, we are still experiencing the issue (in US Midwest) with the 0-byte error. The CDN is connecting to sni1gl.wpc.nucdn.net [152.195.19.97].

[oldium]

I am in the Czech Republic, IP 152.199.21.175, and have the 0-size CDN file problem.

[dan-mba]

Getting the 0-byte issue in Florida. CDN is connecting to sni1gl.wpc.nucdn.net with IP 152.195.19.97

[ItzLevvie]

I am in the Czech Republic, IP 152.199.21.175, and have the 0-size CDN file problem.

Are you still seeing this happen on 152.199.21.175?

[oldium]

Tested ping cdn.winget.microsoft.com to verify IP 152.199.21.175 and winget source update to update sources - it works fine now.

[dan-mba]

Getting the 0-byte issue in Florida. CDN is connecting to sni1gl.wpc.nucdn.net with IP 152.195.19.97

Still getting the zero byte failure here.

[aetonsi]

0-bytes package problem still frequently present in Italy and Nederland (vpn).

I ran winget source update multiple times, tried to update winget, tried to update the package manager, nothing worked.

Then, randomly it finally worked.

CDN (cdn.winget.microsoft.com) points to sni1gl.wpc.nucdn.net with ip 152.199.21.175.

Log:

2022-11-22 11:25:11.002 [CORE] WinGet, version [1.4.3132-preview], activity [{443763C3-CDCC-4F30-9B60-CB1D5754AA4E}]
...
2022-11-22 11:25:11.003 [CORE] Package: Microsoft.DesktopAppInstaller v1.19.3132.0
...
2022-11-22 11:25:13.967 [CORE] WinINet downloading from url: https://cdn.winget.microsoft.com/cache/source.msix
2022-11-22 11:25:13.967 [CORE] Download request status success.
2022-11-22 11:25:13.967 [CORE] Download size: 0
2022-11-22 11:25:13.968 [CORE] Download completed.

---

I run a simple powershell script to fetch the filesize: 1..20 | % { curl -L -I https://cdn.winget.microsoft.com/cache/source.msix 2>&1 | findstr /i length } and this is the result:

Content-Length: 0
Content-Length: 5262159
Content-Length: 5262159
Content-Length: 5262159
Content-Length: 5262159
Content-Length: 0
Content-Length: 5262159
Content-Length: 5262159
Content-Length: 0
Content-Length: 0
Content-Length: 0
Content-Length: 0
Content-Length: 0
Content-Length: 5262159
Content-Length: 0
Content-Length: 5262159
Content-Length: 5262159
Content-Length: 5262159
Content-Length: 0
Content-Length: 5262159

[denelon]

Thanks for reporting this. We're still working with the CDN provider to see what else can be done to resolve this issue. We've now resorted to purging the cache after each publish run.

[petercrabtree]

This is reliably broken for me in Florida / Frontier. cdn.winget.microsoft.com resolves to 152.195.19.97 (sni1gl.wpc.nucdn.net) and returns a 0 byte result 100/100 attempts.

[github-account1111]

https://cdn.winget.microsoft.com/cache/source.msix

The file downloads fine.
And the ping command works fine (and I don't believe it ever didn't work).
I've tried using winget from 5 completely different locations this month and couldn't install or update in any of them regardless of how many times I retried.

I think this is a client issue, not a CDN one.

[denelon]

@github-account1111 can you run an example of attempting to perform an install with "--verbose-logs" and share the results with the logs?

[github-account1111]

> winget install --id CPUID.HWMonitor --verbose-logs
Found CPUID HWMonitor [CPUID.HWMonitor] Version 1.46
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://download.cpuid.com/hwmonitor/hwmonitor_1.46.exe
  ██████████████████████████████  1.37 MB / 1.37 MB
Successfully verified installer hash
Starting package install...
Successfully installed

WinGet-2022-11-23-00-16-26.759.log
WinGet-CPUID.HWMonitor.1.46-2022-11-23-00-16-30.292.log

[denelon]

@github-account1111 the log shows success.
What are the results of winget list CPUID?

I was able to install and run it on my machine.

 denelon  winget install CPUID.HWMonitor
Found CPUID HWMonitor [CPUID.HWMonitor] Version 1.47
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://download.cpuid.com/hwmonitor/hwmonitor_1.47.exe
  ██████████████████████████████  1.39 MB / 1.39 MB
Successfully verified installer hash
Starting package install...
Successfully installed
 denelon  winget list hwmonitor
Name                 Id              Version Source
----------------------------------------------------
CPUID HWMonitor 1.47 CPUID.HWMonitor 1.47    winget
 denelon  winget list CPUID
Name                 Id              Version Source
----------------------------------------------------
CPUID HWMonitor 1.47 CPUID.HWMonitor 1.47    winget
 denelon  winget uninstall CPUID.HWMonitor
Found CPUID HWMonitor [CPUID.HWMonitor]
Starting package uninstall...
Successfully uninstalled

[spences10]

I can uninstall and install apps but when I try winget upgrade --all I get the Failed in attempting to update the source: winget message.

I tried winget source reset --force then when I try winged --info or winget upgrade --all again I get this message:

PS C:\Users\me> winget upgrade --all
Failed in attempting to update the source: winget
Name                                  Id                               Version Available Source
-----------------------------------------------------------------------------------------------
Firefox Developer Edition (x64 en-US) Mozilla.Firefox.DeveloperEdition 107.0   108.0b2   winget
1 upgrades available.

then upgrade all again:

PS C:\Users\me> winget upgrade --all
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 the current machine's 2-letter geographic region to be sent to the backend service to function properly (ex. "US").

☝️ I don't know what this means

I have an empty settings.json file, here's what winget --info gives me:

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

Windows: Windows.Desktop v10.0.22623.891
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

[denelon]

@spences10 it looks like you're hitting the zero-byte file CDN problem that we're encountering:

• Publishing is down again (failed to update source) #2718

[spences10]

@spences10 it looks like you're hitting the zero-byte file CDN problem that we're encountering:

• Publishing is down again (failed to update source) #2718

So, is it just a wait for it to be fixed kinda thing and carry on as normal until it's fixed?

[denelon]

@spences10 yes, we're working through the issue. We're in the process of changing the default behavior to flush the cache automatically with each publish event. There were some API changes on the back end that shouldn't have had any impact, but clearly something changed with our CDN provider's ability to distribute the file globally. It's inconsistent so it's being illusive to completely resolve. We keep getting false positives. For some reason, the CDN is caching a zero-byte file when the file is approximately 5mb. https://cdn.winget.microsoft.com/cache/source.msix is the offending URL.

[github-account1111]

@denelon it installed the old version.
That is the whole issue.
It refuses to install latest versions or upgrade anything.
Half my software has been outdated for months now.
In the example with HWMonitor, it still thinks that 1.46 is the latest whereas 1.47 has been released and should've been installed (like it did in your case).

> winget list CPUID
Name                 Id              Version Source
----------------------------------------------------
CPUID HWMonitor 1.46 CPUID.HWMonitor 1.46    winget

#2666 (comment)

[denelon]

Do you get a zero-byte file from https://cdn.winget.microsoft.com/cache/source.msix ?

You may have an "old" copy of the PreIndexed package.

What do you get for winget search CPUID.HWMonitor ?

[github-account1111]

No, that downloads a 5MB file.

> winget search CPUID.HWMonitor
Name            Id              Version Source
-----------------------------------------------
CPUID HWMonitor CPUID.HWMonitor 1.46    winget

[denelon]

OK, that's a good sign.

There may be a stale cache on the system then.

Try winget source reset --force in administrator mode to get the "winget" and "msstore" sources reset.

If that works, then try winget source update to get the cache downloaded and installed.

Then try the search again.

[github-account1111]

That's what I did in #2696 (comment) upon your request.

[denelon]

What do you get for:
winget list Microsoft.Winget.Source_8wekyb3d8bbwe

[github-account1111]

> winget list Microsoft.Winget.Source_8wekyb3d8bbwe
Name                                    Id                                    Version
-----------------------------------------------------------------------------------------------
Windows Package Manager Source (winget) Microsoft.Winget.Source_8wekyb3d8bbwe 2022.923.2026.688

[denelon]

@github-account1111 that looks like it's pretty far out of date. YYYY.MMDD is the first part of the Version.

I've currently got:

Windows Package Manager Source (winget)  Microsoft.Winget.Source_8wekyb3d8bbwe 2022.1128.2219.474

[github-account1111]

What's out of date, and is there anything that can be done to fix it and prevent it from happening in the future?

[denelon]

I believe we have finally resolved our CDN related issue. Try downloading and installing the latest source.msix. If it was in fact the CDN issue, your system wasn't getting the latest version of the cache and ended up getting stale and staying out of date. Also check the TTL in settings. If it's not specified, the default timeout is 5 minutes. If it's set to "0" then it would never update.

[joshsleeper]

winget updated without issue for me as of an hour or two ago!
thanks a bunch to everyone involved in getting that sorted out~

[spences10]

Just tried winget upgrade --all works for me now

[aetonsi]

winget source update working. 0 byte file problem no longer present.

Thanks

[github-account1111]

Wow I guess it was a CDN issue after all.
Did a source reset followed by a source update, and now all the updates have finally shown up and gone through after all these months.

Amazing.
I think it's safe to close this then?