Error with winget update - Failed in attempting to update the source: winget
Brief description of your issue
When trying to do winget update I get an error message Failed in attempting to update the source: winget.
Steps to reproduce
Run winget update
Expected behavior
It should refresh the sources successfully and list packages that need updating.
Actual behavior
The error message Failed in attempting to update the source: winget appears.
Environment
``
Windows Package Manager v1.10.340
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.26100.3775
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.25.340.0
Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User) %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User) %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root C:\Program Files\WinGet\Packages
Portable Package Root (x86) C:\Program Files (x86)\WinGet\Packages
Installer Downloads %USERPROFILE%\Downloads
Configuration Modules %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules
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
Admin Setting State
--------------------------------------------------
LocalManifestFiles Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride Disabled
LocalArchiveMalwareScanOverride Disabled
ProxyCommandLineOptions Disabled
DefaultProxy Disabled
``
We've found some similar issues:
- #3525 , similarity score: 91%
- #4992 , similarity score: 85%
- #1826 , similarity score: 84%
- #3098 , similarity score: 84%
- #3829 , similarity score: 84%
- #2664 , similarity score: 84%
- #3419 , similarity score: 83%
- #3303 , similarity score: 81%
- #4876 , similarity score: 81%
If any of the above are duplicates, please consider closing this issue out and adding additional context in the original issue.
Note: You can give me feedback by π or π this comment.
https://cdn.winget.microsoft.com/cache/source.msix currently returns 403 for me. Looks like it might be a Microsoft CDN issue. Hopefully it's temporary/resolved soon.
I noticed this issue last night on a fresh install of windows. Now noticing it again on another device, this time at work. Still seems to be happening.
Using the latest version of WinGet, the URL should be: https://cdn.winget.microsoft.com/cache/source2.msix
If you get an error in the browser, try using "In Private" browsing.
@denelon, thank you for that insight. I confirmed the URI you provided works using "In Private" browsing. I see references to both new and old URIs in the log:
2025-04-09 11:28:59.720 [CORE] WinGet, version [1.10.340], activity [{30045198-6AC5-4E21-AE6B-5151722EC42C}]
2025-04-09 11:28:59.720 [CORE] OS: Windows.Desktop v10.0.22631.5189
2025-04-09 11:28:59.720 [CORE] Command line Args: "C:\Users\[username]\AppData\Local\Microsoft\WindowsApps\winget.exe" update Microsoft.DesktopAppInstaller
2025-04-09 11:28:59.720 [CORE] Package: Microsoft.DesktopAppInstaller v1.25.340.0
2025-04-09 11:28:59.720 [CORE] IsCOMCall:0; Caller: winget-cli
2025-04-09 11:28:59.726 [CLI ] WinGet invoked with arguments: 'update' 'Microsoft.DesktopAppInstaller'
2025-04-09 11:28:59.727 [CLI ] Found subcommand: update
2025-04-09 11:28:59.727 [CLI ] Leaf command to execute: root:upgrade
2025-04-09 11:28:59.731 [CLI ] Executing command: upgrade
2025-04-09 11:28:59.737 [REPO] Default source requested, multiple sources available, adding all to source references.
2025-04-09 11:28:59.737 [REPO] Adding to source references msstore
2025-04-09 11:28:59.737 [CORE] Default proxy is not set
2025-04-09 11:28:59.737 [REPO] REST HTTP Client helper does not use proxy
2025-04-09 11:28:59.737 [REPO] Adding to source references winget
2025-04-09 11:28:59.737 [CLI ] Created authentication arguments. Mode: silentPreferred, Account:
2025-04-09 11:28:59.747 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2025-04-09 11:28:59.747 [CORE] Found matching extension.
2025-04-09 11:28:59.750 [REPO] Source `winget` after auto update time [15 mins]; it has been at least 10061 mins
2025-04-09 11:28:59.755 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2025-04-09 11:28:59.755 [CORE] Found matching extension.
2025-04-09 11:29:00.022 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(313)\WindowsPackageManager.dll!00007FFC5AD2FAA8: (caller: 00007FFC5AF500AA) Exception(1) tid(6200) 8051100F
2025-04-09 11:29:00.022 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(125)\WindowsPackageManager.dll!00007FFC5B03040F: (caller: 00007FFC5AF5251E) LogHr(1) tid(6200) 8051100F Msg:[PreIndexedPackageUpdateCheck failed on location: https://cdn.winget.microsoft.com/cache/source2.msix -- C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(313)\WindowsPackageManager.dll!00007FFC5AD2FAA8: (caller: 00007FFC5AF500AA) Exception(1) tid(6200) 8051100F ]
2025-04-09 11:29:00.053 [CORE] Downloading to path: C:\Users\[username]\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix
2025-04-09 11:29:00.053 [CORE] Started applying motw to C:\Users\[username]\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 3
2025-04-09 11:29:00.071 [CORE] Finished applying motw
2025-04-09 11:29:00.071 [CORE] WinINet downloading from url: https://cdn.winget.microsoft.com/cache/source.msix
2025-04-09 11:29:00.168 [CORE] Error retrieving header [1]: 12150
2025-04-09 11:29:00.169 [CORE] Download hash: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
2025-04-09 11:29:00.169 [CORE] Download completed.
2025-04-09 11:29:00.170 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(313)\WindowsPackageManager.dll!00007FFC5AD2FAA8: (caller: 00007FFC5AF53984) Exception(2) tid(6200) 8051100F
2025-04-09 11:29:00.170 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(96)\WindowsPackageManager.dll!00007FFC5B02E285: (caller: 00007FFC5AF3673A) LogHr(2) tid(6200) 8051100F Msg:[C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\MsixInfo.cpp(313)\WindowsPackageManager.dll!00007FFC5AD2FAA8: (caller: 00007FFC5AF53984) Exception(2) tid(6200) 8051100F ]
2025-04-09 11:29:00.170 [REPO] Source add/update failed, waiting 2184 milliseconds and retrying: winget
[snip]
The second line at 11:29:00.022 contains an error related to the new URI: PreIndexedPackageUpdateCheck failed on location: https://cdn.winget.microsoft.com/cache/source2.msix. It then apparently continues to try with the old URI and also fails.
Thank you very much for looking into this.
Same issue with winget version v1.10.340
Using the latest version of WinGet, the URL should be: https://cdn.winget.microsoft.com/cache/source2.msix
For some reason, every uninstall, reinstall, reset, force and even a manual delete folder give me the old url (cache maybe?). Downloading this file and installing with normal double click, fixed it.
Just pointing that this error starts for me only today.
I've posted in #5368 just as it was closed, the solutions provided only seem to be temporary.
Using the latest version of WinGet, the URL should be: https://cdn.winget.microsoft.com/cache/source2.msix
If you get an error in the browser, try using "In Private" browsing.
This fixed it for me
Hm, I didn't think there would be a difference between using Add-AppxPackage https://cdn.winget.microsoft.com/cache/source2.msix and manually downloading and installing source2.msix, but I tried it now, and it works, hopefully not temporarily this time.
Update: happened again. Winget source update fails. So the solution is only temporary, unless I'm missing some step, I don't know anymore.
Windows Package Manager v1.10.340
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.26100.3775
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.25.340.0
Winget Directories
-----------------------------------------------------------------------------------------------------------------------
Logs %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diagβ¦
User Settings %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settβ¦
Portable Links Directory (User) %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User) %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root C:\Program Files\WinGet\Packages
Portable Package Root (x86) C:\Program Files (x86)\WinGet\Packages
Installer Downloads %USERPROFILE%\Downloads
Configuration Modules %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules
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
Admin Setting State
--------------------------------------------------
LocalManifestFiles Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride Disabled
LocalArchiveMalwareScanOverride Disabled
ProxyCommandLineOptions Disabled
DefaultProxy Disabled
Using the latest version of WinGet, the URL should be: https://cdn.winget.microsoft.com/cache/source2.msix If you get an error in the browser, try using "In Private" browsing.
This fixed it for me
It didn't work!
Using Add-AppxPackage https://cdn.winget.microsoft.com/cache/source2.msix did not work for me either on a fresh Windows 11 installation. However, running these commands from the WinGet troubleshooting page on Microsoft Learn did the trick:
Install-PackageProvider -Name NuGet -Force | Out-Null
Install-Module -Name Microsoft.WinGet.Client -Force -Repository PSGallery | Out-Null
Repair-WinGetPackageManager -Force -Latest
This seems to start (on two computers already) when updating the Windows Package Manager Source (winget) V2 app, it has updated by me today to 2025.410.1452.10 which is when the issues started.
However, running these commands from the WinGet troubleshooting page on Microsoft Learn did the trick:
Install-PackageProvider -Name NuGet -Force | Out-Null
This seems to have worked for me on a Windows 10 computer with the issue (the two other commands failed)
I had this issue on a clean install of Windows 11 24H2 today. Downloading and installing the latest release of winget off of GitHub fixed the issue for me.
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
Done!
This has been working fine for me until two days ago, then similar issues (which is why I found this thread). However, it has been working fine again this since morning.
@denelon I'd like to know if I should be using source or source2 when customizing Windows 11 builds that are the latest 'patch Tuesday' builds (obtained from Azure Platform Images). I run automated OS customization, but it seems strange that I always have install both Microsoft.DesktopAppInstaller_8wekyb3d8bbwe and source manually before being able to run winget. (See code in my previous comment). Any clues would be appreciated!
Ok, well I tried building with source2.msix but then it couldn't find any packages. Does anyone have a clear idea what's going on?
I don't know why I did but using super admin is the key.
Unfortunately, this is the most common point of failure for folks and there are many reasons it could happen. This is where applications leveraging the Internet suffer the most. The most common reason for failure is related to networking. It could be DNS, packet loss, or any number of other network related failures. Sometimes changing the default downloader in WinGet settings from "DO" (Delivery Optimization) to "wininet" does the trick.
When it's not the devices network connectivity (or our CDN) it falls into two primary reasons. The first is that the version of WinGet isn't recent. The second has to do with the permissions used on the device when the first WinGet command is invoked.
Dealing with the first requires updating Apps via the Microsoft Store or using the Microsoft.WinGet.Client PowerShell module and running Repair-WinGetPackageManager -Force -Latest. Optionally the dependencies and the client can be downloaded from the GitHub Releases page and manually installed.
Dealing with the second requires removing the "old" source and updating it. It can be removed via Apps in Windows Settings or it can be uninstalled using WinGet (the uninstall doesn't require the source to be current). You can filter on "winget", and you are looking for an entry like:
These are not the only reasons updating the source fails, but they are the most common we see. We've implemented retry logic and several other things to improve the situation, but it still happens on occasion.
@denelon I think I didn't represent my situation fully. I'm customising an Azure Platform image unattended using Azure Image Builder (it's basically still just Hashicorp's Packer). The script I posted three comments ago is the only way I've been able to get the Packer user to be able to use winget. The script provisions the existing winget install to the Packer user. Normally when a user logs in, app provisioning happens automatically. But for Packer, it's unattended, so that never happens.
If source2.msix breaks winget, but with source.msix everything is found and installs as expected, I must surmise that the latest winget is not yet incorporated into the platform image. (If I'm correct, my challenge would be to Microsoft, "Why aren't you keeping winget up-to-date in your Azure platform images?" Maybe you can forward that internally?)
I've already tried Microsoft.WinGet.Client/Repair-WinGetPackageManager and it results in a broken winget in the unattended scenario.
Other stuff I've tried that hasn't worked:
$URL = "https://api.github.com/repos/microsoft/winget-cli/releases/latest"
$URL = (Invoke-WebRequest -Uri $URL).Content | ConvertFrom-Json |
Select-Object -ExpandProperty "assets" |
Where-Object "browser_download_url" -Match '.msixbundle' |
Select-Object -ExpandProperty "browser_download_url"
Invoke-WebRequest -Uri $URL -OutFile "Setup.msix" -UseBasicParsing
Add-AppxPackage -Path "Setup.msix"
^ didn't work because the bundle is missing the required VClibs and UI.Xaml, if I remember correctly.
Also created this one which did work, but was ugly as sin: https://github.com/microsoft/winget-cli/issues/256#issuecomment-2661354749
But abandoned that of course because the script a few posts up is so much cleaner. However I'm now worried that my current solution is not future-proof since I'm using the old source. It was a worrying situation when I was rebuilding all our desktops on 'patch Tuesday' and all my pipelines failed because source.msix had gone missing from the CDN. Perhaps you know of a better solution for this kind of scenario?
Our intent is to have folks leverage the "Repair-WinGetPackageManager" cmdlet to get the latest version of WinGet installed and functioning for "user" based usage.
The unattended scenarios and the system context both provide unique challenges. For those, I'd suggest using the Microsoft.WinGet.Client PowerShell module. It's certainly not perfect, and there isn't full feature parity with the CLI, but that way the COM APIs get invoked which is required in system context, and PowerShell provides "rich" objects as opposed to strings to parse coming out of the CLI.
Note: Installing packages in system context only works if they install "machine wide" vs. "user scope".
The original source.msix is only used by earlier versions of the client and is maintained to hopefully allow the client to upgrade (via Mirosoft Store update or winget upgrade --all to a more recent version of WinGet leveraging source2.msix.
Versions earlier than WinGet 1.6 don't support dependencies, so the upgrade is only likely to work with "luck" based on the dependencies already being installed on the device.
We've been dealing with a lot of legacy challenges in terms of all the "chicken and egg" problems related to getting the latest version of WinGet on Windows Desktop to begin with (when it isn't a functional version in the ISO). Repair-WinGetPackageManager was built to help provide an automatable way to bootstrap WinGet and have it functional regardless of which version is presently installed on a device.
We do offer the "main" package for the App Installer as well as the dependencies needed in our releases. That should support "offline" distribution/installation and it's a bit easier to automate against for folks not wanting the performance hits encountered with Repair-WinGetPackageManager.
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
Done!
This has been working fine for me until two days ago, then similar issues (which is why I found this thread). However, it has been working fine again this since morning.
I had issues on a clean install of Windows 11 Dev Channel and I stumbled upon this and it works now!
Thank you so much!
I am also facing this issue and I haven't seen this failure mode reported yet
PS C:\WINDOWS\system32> winget --info
Windows Package Manager v1.12.350
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.19045.6466
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.27.350.0
Winget Directories
-------------------------------------------------------------------------------------------------------------------------------
Logs %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
User Settings %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json
Portable Links Directory (User) %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User) %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root C:\Program Files\WinGet\Packages
Portable Package Root (x86) C:\Program Files (x86)\WinGet\Packages
Installer Downloads D:\Users\Clement\Downloads
Configuration Modules %LOCALAPPDATA%\Microsoft\WinGet\Configuration\Modules
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
Admin Setting State
--------------------------------------------------
LocalManifestFiles Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride Disabled
LocalArchiveMalwareScanOverride Disabled
ProxyCommandLineOptions Disabled
DefaultProxy Disabled
When I try to update sources, this happens
PS C:\WINDOWS\system32> winget source list
Name Argument Explicit
------------------------------------------------------------------
msstore https://storeedgefd.dsx.mp.microsoft.com/v9.0 false
winget https://cdn.winget.microsoft.com/cache false
winget-font https://cdn.winget.microsoft.com/fonts true
PS C:\WINDOWS\system32> winget source update
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
ββββββββββββββββββββββββββββββ 2.38 MB / 2.38 MB
Cancelled
Updating source: winget-font...
Done
and the logs for winget source update shows it is downloading from the right URL but failing to open it? I checked the directory and the file does exist
2025-11-13 01:17:47.552 [CORE] WinGet, version [1.12.350], activity [{E5BBB7A2-64C2-4392-93DB-B490D6A537C7}]
2025-11-13 01:17:47.553 [CORE] OS: Windows.Desktop v10.0.19045.6466
2025-11-13 01:17:47.553 [CORE] Command line Args: "C:\Users\Clement\AppData\Local\Microsoft\WindowsApps\winget.exe" source update
2025-11-13 01:17:47.553 [CORE] Package: Microsoft.DesktopAppInstaller v1.27.350.0
2025-11-13 01:17:47.553 [CORE] IsCOMCall:0; Caller: winget-cli
2025-11-13 01:17:47.568 [CLI ] WinGet invoked with arguments: 'source' 'update'
2025-11-13 01:17:47.568 [CLI ] Found subcommand: source
2025-11-13 01:17:47.568 [CLI ] Found subcommand: update
2025-11-13 01:17:47.568 [CLI ] Leaf command to execute: root:source:update
2025-11-13 01:17:47.569 [CLI ] Executing command: update
2025-11-13 01:17:47.584 [REPO] Named source requested, found: msstore
2025-11-13 01:17:47.584 [CORE] Default proxy is not set
2025-11-13 01:17:47.584 [REPO] REST HTTP Client helper does not use proxy
2025-11-13 01:17:47.585 [REPO] Named source to be updated, found: msstore
2025-11-13 01:17:47.699 [REPO] Named source requested, found: winget
2025-11-13 01:17:47.700 [REPO] Named source to be updated, found: winget
2025-11-13 01:17:47.708 [CORE] Examining extension: PFN = Microsoft.Winget.Fonts.Source_8wekyb3d8bbwe, ID = IndexDB
2025-11-13 01:17:47.708 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2025-11-13 01:17:47.994 [CORE] Downloading to path: D:\Users\Clement\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix
2025-11-13 01:17:47.995 [CORE] Started applying motw to D:\Users\Clement\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 3
2025-11-13 01:17:47.997 [CORE] Finished applying motw
2025-11-13 01:17:47.997 [CORE] WinINet downloading from url: https://cdn.winget.microsoft.com/cache/source2.msix
2025-11-13 01:17:48.110 [CORE] Download hash: 0a409f3c934f2027b5d3aa42a63e494b28f7310d642c60ef5c54258c333bc79d
2025-11-13 01:17:48.110 [CORE] Download completed.
2025-11-13 01:17:48.177 [CORE] Started trust validation of msix at: D:\Users\Clement\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix
2025-11-13 01:17:48.231 [CORE] Result for certificate chain validation of Microsoft origin: 0
2025-11-13 01:17:48.282 [CORE] Result for trust info validation of the msix: 0
2025-11-13 01:17:48.282 [CORE] Starting AddPackage operation #0: file:///D:/Users/Clement/AppData/Local/Temp/WinGet/Microsoft.Winget.Source_8wekyb3d8bbwe.msix Options: { SkipReputationCheck = 1, ExpectedDigests = {} }
2025-11-13 01:17:48.283 [CORE] Begin waiting for operation #0
2025-11-13 01:17:48.283 [CORE] Begin blocking for operation #0
2025-11-13 01:17:48.293 [CORE] Deployment operation #0: error 0x80070003: Opening the package from location Microsoft.Winget.Source_8wekyb3d8bbwe.msix failed.
2025-11-13 01:17:48.293 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FFEB3C04E7B: (caller: 00007FFEB3C007D3) Exception(1) tid(2960) 80070003 The system cannot find the path specified.
Msg:[Operation failed: error 0x80070003: Opening the package from location Microsoft.Winget.Source_8wekyb3d8bbwe.msix failed.]
2025-11-13 01:17:48.299 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(96)\WindowsPackageManager.dll!00007FFEB3D5E575: (caller: 00007FFEB3C611ED) LogHr(1) tid(2960) 80070003 The system cannot find the path specified.
Msg:[C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FFEB3C04E7B: (caller: 00007FFEB3C007D3) Exception(1) tid(2960) 80070003 The system cannot find the path specified.
Msg:[Operation failed: error 0x80070003: Opening the package from location Microsoft.Winget.Source_8wekyb3d8bbwe.msix failed.]
]
2025-11-13 01:17:48.299 [REPO] Source add/update failed, waiting 7279 milliseconds and retrying: winget
2025-11-13 01:17:55.601 [CORE] Examining extension: PFN = Microsoft.Winget.Fonts.Source_8wekyb3d8bbwe, ID = IndexDB
2025-11-13 01:17:55.601 [CORE] Did not find extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2025-11-13 01:17:55.832 [CORE] Downloading to path: D:\Users\Clement\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix
2025-11-13 01:17:55.833 [CORE] Started applying motw to D:\Users\Clement\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 3
2025-11-13 01:17:55.833 [CORE] Finished applying motw
2025-11-13 01:17:55.833 [CORE] WinINet downloading from url: https://cdn.winget.microsoft.com/cache/source2.msix
2025-11-13 01:17:55.857 [CORE] Download hash: 0a409f3c934f2027b5d3aa42a63e494b28f7310d642c60ef5c54258c333bc79d
2025-11-13 01:17:55.857 [CORE] Download completed.
2025-11-13 01:17:55.905 [CORE] Started trust validation of msix at: D:\Users\Clement\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix
2025-11-13 01:17:55.947 [CORE] Result for certificate chain validation of Microsoft origin: 0
2025-11-13 01:17:55.984 [CORE] Result for trust info validation of the msix: 0
2025-11-13 01:17:55.984 [CORE] Starting AddPackage operation #1: file:///D:/Users/Clement/AppData/Local/Temp/WinGet/Microsoft.Winget.Source_8wekyb3d8bbwe.msix Options: { SkipReputationCheck = 1, ExpectedDigests = {} }
2025-11-13 01:17:55.984 [CORE] Begin waiting for operation #1
2025-11-13 01:17:55.984 [CORE] Begin blocking for operation #1
2025-11-13 01:17:55.991 [CORE] Deployment operation #1: error 0x80070003: Opening the package from location Microsoft.Winget.Source_8wekyb3d8bbwe.msix failed.
2025-11-13 01:17:55.991 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FFEB3C04E7B: (caller: 00007FFEB3C007D3) Exception(2) tid(2960) 80070003 The system cannot find the path specified.
Msg:[Operation failed: error 0x80070003: Opening the package from location Microsoft.Winget.Source_8wekyb3d8bbwe.msix failed.]
2025-11-13 01:17:55.996 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(964)\WindowsPackageManager.dll!00007FFEB3D5F2E7: (caller: 00007FFEB3B12583) LogHr(2) tid(2960) 80070003 The system cannot find the path specified.
Msg:[C:\__w\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FFEB3C04E7B: (caller: 00007FFEB3C007D3) Exception(2) tid(2960) 80070003 The system cannot find the path specified.
Msg:[Operation failed: error 0x80070003: Opening the package from location Microsoft.Winget.Source_8wekyb3d8bbwe.msix failed.]
]
2025-11-13 01:17:55.996 [REPO] Failed to update source: winget
2025-11-13 01:17:55.998 [REPO] Named source requested, found: winget-font
2025-11-13 01:17:55.999 [REPO] Named source to be updated, found: winget-font
2025-11-13 01:17:56.004 [CORE] Examining extension: PFN = Microsoft.Winget.Fonts.Source_8wekyb3d8bbwe, ID = IndexDB
2025-11-13 01:17:56.004 [CORE] Found matching extension.
2025-11-13 01:17:56.100 [CLI ] Leaf command succeeded: root:source:update
I have already tried Repair-WinGetPackageManager -Force -Latest (which produces no output) and uninstalling the old source via "App and Features" but neither fixed the issue