winget wont upgrade on Windows 11

Question

I need to upgrade winget onto new fresh Windows 11 23H2 installations (already fully updated).

I have tried manual GUI installation clicking on the .msixbundle file downloaded from https://github.com/microsoft/winget-cli but it doesn't succeed, with no clear informations/suggestions about.

I then tried to open a PowerShell session with admin privileges and run winget upgrade MicrosoftAppInstaller. The CLI returns to me error 0x8a15000f : Data required by the source is missing

I would like to upgrade the default Win11 versione 1.17.10691.0 to the latest one

Answer 1

According to Ramhound suggestions the issue seems to be solved.

winget source list returns

Nome    Argomento                                     Contenuti espliciti
-------------------------------------------------------------------------
msstore https://storeedgefd.dsx.mp.microsoft.com/v9.0 false
winget  https://cdn.winget.microsoft.com/cache        false

but the content of winget xml file returns:

<Error>
<Code>ResourceNotFound</Code>
<Message>The specified resource does not exist. RequestId:e4fa72b3-101e-004d-564e-196f85000000 Time:2024-10-08T06:52:36.9634238Z</Message>
</Error>

Then, after running winget source update, I finally got the latest version 1.23.1911.0

Please Note: the issue I have reported does not occur on fresh Windows 10 22H2 installations (already fully updated). Why is there such different behaviour between Win10 and Win11?

Answer 2

The answer I posted recently works in most cases. I tried on other more recent machines where I installed Windows 11 in the same way. In these cases the solution does not work.

The problem seems to be due to a failed update of the winget repositories (I delete the comment to my previous answer in order to expand the issue herein). I tried to follow the workaround proposed here

Still on some test machines this patch works, on few others it does not.

In terms of reproducibility on all the test machines (Intel i5 from the 6th to the 12th generation) I installed the same Windows 11 23H2 iso image. On all the test machines I did all the possible updates proposed by Windows Update.

I have no further clues about till now...

UPDATE (April the 10th, 2025)

I have encountered another case today on a fresh installation of Windows 11 Pro 24H2.

I have tried the method proposed by prosky without success, winget update --all returns as follows:

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").
Do you agree to all the source agreements terms?
[Y] Yes  [N] No: y
Failed when searching source: winget
An unexpected error occurred while executing the command:
0x8a15000f : Data required by the source is missing

Nevertheless I suppose that suche this new case could be a bit different. Here there is my log file:

2025-04-10 10:47:15.535 [CORE] Package: Microsoft.DesktopAppInstaller v1.21.10120.0
2025-04-10 10:47:15.535 [CORE] IsCOMCall:0; Caller: winget-cli
2025-04-10 10:47:15.584 [CLI ] WinGet invoked with arguments: 'source' 'update'
2025-04-10 10:47:15.634 [CLI ] Found subcommand: source
2025-04-10 10:47:15.654 [CLI ] Found subcommand: update
2025-04-10 10:47:15.655 [CLI ] Leaf command to execute: root:source:update
2025-04-10 10:47:15.678 [CLI ] Executing command: update
2025-04-10 10:47:15.947 [REPO] Named source requested, found: msstore
2025-04-10 10:47:15.974 [REPO] Named source to be updated, found: msstore
2025-04-10 10:47:16.154 [REPO] Named source requested, found: winget
2025-04-10 10:47:16.176 [REPO] Named source to be updated, found: winget
2025-04-10 10:47:16.183 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2025-04-10 10:47:16.751 [FAIL] WindowsPackageManager.dll!00007FF9F5259422: ReturnHr(1) tid(298) 801901A0 Impossibile attenersi all'intervallo richiesto (416).
Msg:[C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\HttpStream\HttpClientWrapper.cpp(132)\WindowsPackageManager.dll!00007FF9F5251D4A: (caller: 00007FF9F4F8B970) Exception(1) tid(298) 801901A0 Impossibile attenersi all'intervallo richiesto (416).


]
2025-04-10 10:47:16.751 [FAIL] WindowsPackageManager.dll!00007FF9F4FE75F1: LogHr(1) tid(298) 801901A0 Impossibile attenersi all'intervallo richiesto (416).
2025-04-10 10:47:16.845 [FAIL] C:__w\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(95)\WindowsPackageManager.dll!00007FF9F528134F: (caller: 00007FF9F513179C) LogHr(2) tid(298) 801901A0 Impossibile attenersi all'intervallo richiesto (416).
Msg:[winrt::hresult_error: Impossibile attenersi all'intervallo richiesto (416).] 


2025-04-10 10:47:16.881 [REPO] Source add/update failed, waiting 9868 milliseconds and retrying: winget
2025-04-10 10:47:26.764 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2025-04-10 10:47:26.785 [FAIL] WindowsPackageManager.dll!00007FF9F5259422: ReturnHr(2) tid(298) 801901A0 Impossibile attenersi all'intervallo richiesto (416).
Msg:[C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\HttpStream\HttpClientWrapper.cpp(132)\WindowsPackageManager.dll!00007FF9F5251D4A: (caller: 00007FF9F4F8B970) Exception(2) tid(298) 801901A0 Impossibile attenersi all'intervallo richiesto (416).


]
2025-04-10 10:47:26.785 [FAIL] WindowsPackageManager.dll!00007FF9F4FE75F1: LogHr(3) tid(298) 801901A0 Impossibile attenersi all'intervallo richiesto (416).
2025-04-10 10:47:26.785 [FAIL] C:__w\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(831)\WindowsPackageManager.dll!00007FF9F528099E: (caller: 00007FF9F506B115) LogHr(4) tid(298) 801901A0 Impossibile attenersi all'intervallo richiesto (416).
Msg:[winrt::hresult_error: Impossibile attenersi all'intervallo richiesto (416).] 


2025-04-10 10:47:26.785 [REPO] Failed to update source: winget
2025-04-10 10:47:26.949 [CLI ] Leaf command succeeded: root:source:update

Damn, such issue show a kind of cursed unknown recurrence.

Answer 3

I spent some time troubleshooting winget in PowerShell running as Administrator. I was able to find winget logs in

C:\Users\Administrator\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir\WinGet-*

I noticed that winget complained in the log that the user was not logged in:

2025-02-17 10:48:39.401 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FF8C70FCA3B: (caller: 00007FF8C70F8779) Exception(1) tid(44b0) 80073D19 An error occurred because a user was logged off.
    Msg:[Operation failed: Deployment Add operation with target volume C: on Package Microsoft.Winget.Source_2025.217.1918.20_neutral__8wekyb3d8bbwe from:   failed with error 0x80073D19. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.] 

Then I logged in as the local Administrator and ran winget update --all. Winget worked fine and upgraded some packages.

Then I logged in as myself again, ran PowerShell as Administrator and ran with the same arguments - it worked this time (without upgrading anything).

I guess running winget when logged in as Administrator made it pass some hurdle. As a result, winget created some file, directory or registry key, and now it works as Administrator even when I'm logged in as an ordinary user.

Answer 4

I found such issue thread on GitHub (it should be the official reference for winget). In that discussion bedalus suggests another possible solution:

I've been running as an admin:

Find-PackageProvider -Name NuGet -ForceBootstrap -IncludeDependencies -Force
Set-PSRepository -Name PSGallery -InstallationPolicy Trusted
Install-Module -Name PSDownloader -Scope AllUsers
Import-Module PSDownloader
Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
$ProgressPreference = "SilentlyContinue"
Start-Download -Url "https://cdn.winget.microsoft.com/cache/source.msix" -Threads 8 -Force -MaxRetry 3 -Destination ".\source.msix" -NoProgress
Add-AppxPackage -Path ".\source.msix" -ForceApplicationShutdown -ForceUpdateFromAnyVersion

Then exit, start a new shell as admin:

winget source update
winget list --accept-source-agreements

I have not tested the above mentioned approach because the issue (aka the host that was involved in) seems to be reverted today (April the 14th, 2025 winget source update started work again without any other intervention).

Anyway, since such issue seems to have a kind of recurrency (before on 23H2 build, appeared recently in 24H2 build) I will consider such approach a valuable method that neeeds to be furtherly investigated