Open github-account1111 opened 2 years ago
ItzLevvie
commented
2 years ago Failed in attempting to update the source: winget looks to be an issue on your end because I'm not able to reproduce this on a clean installation of Windows 11.
No applicable installer found; see logs for more details. will be fixed by a future winget-pkgs PR.
github-account1111
commented
2 years ago This is also a clean Windows 11 install.
ItzLevvie
commented
2 years ago 1) Do you have any third-party applications installed? 2) What happens when you go to https://winget.azureedge.net/cache/source.msix and install it?
If manually installing the source.msix installs fine for you then the culprit is most likely a permissions issue somewhere in C:\Windows\Temp or somewhere else?
At least from my testing installing MSIX / APPX files via the Windows Package Manager seems to split the installation files between C:\Users\%USERNAME%\AppData\Local\Temp and %SystemRoot%\Temp as there was a user in the past who had incorrect permissions for the %SystemRoot%\Temp folder and changing the permissions for that folder fixed it for them.
Also by clean installation I'm referring to installing Windows 11 via an ISO image / VHDX file and then running Microsoft Store's "Get updates" button to get the latest version of the Windows Package Manager. Official Windows 11 ISOs already have the correct permissions for various OS files and folders, and the correct security descriptors.
You will also probably run into the same issue in Windows Sandbox because it uses your existing OS files to setup a container image which means if there's a third-party application that made changes to some OS files (like .dll files) then Windows Sandbox will get that too.
If you think your OS files are somehow corrupted then you can look into rebuilding your OS files by launching setup.exe from an ISO image which will repair your current Windows installations with fresh files.
github-account1111
commented
2 years ago I mean.. I have Steam, VS Code, OBS, a couple more programs and Store apps. All reputable. I'm very minimal with my Windows installs and diligent with maintaining them and not doing anything breaking. And like I said it's about a week old. If that's all it takes to break winget then maybe make it more resilient? Because I can guarantee you most people are way less minimal with their systems.
I'm actually not even sure if I wanna install whatever you linked there, I'm that cautious.
C:\Users\%USERNAME%\AppData\Local\Tempand%SystemRoot%\Temp
Haven't touched either of those.
Also by clean installation I'm referring to installing Windows 11 via an ISO image / VHDX file and then running Microsoft Store's "Get updates" button to get the latest version of the Windows Package Manager
That is also what I meant and what I did (in addition to Windows Updates).
You will also probably run into the same issue in Windows Sandbox
Not sure what you mean. There isn't even a Store in Sandbox.
If you think your OS files are somehow corrupted then you can look into rebuilding your OS files by launching setup.exe from an ISO image which will repair your current Windows installations with fresh files.
If I need to resort to an in-place upgrade a week into a clean install and cautious usage then there is something seriously wrong and will break again a week after.
github-account1111
commented
2 years ago > winget list
Name Id Version Available Source
-----------------------------------------------------------------------------------------------------------------------
Unigram—Telegram for Windows 38833FF26BA1D.UnigramPreview_g9c9v27… 8.6.7182.0
Signal OpenWhisperSystems.Signal 5.39.0 winget
Intel® Graphics Command Center AppUp.IntelGraphicsExperience_8j3eq9… 1.100.3408.0
CrystalDiskMark CrystalDewWorld.CrystalDiskMark 8.0.4 winget
Docker Desktop Docker.DockerDesktop 4.7.0 winget
Microsoft Edge Microsoft.Edge 100.0.1185.50 winget
Microsoft Edge Update Microsoft Edge Update 1.3.157.61
Microsoft Edge WebView2 Runtime Microsoft.EdgeWebView2Runtime 100.0.1185.50 winget
App Installer Microsoft.DesktopAppInstaller_8wekyb… 1.17.10271.0
HEIF Image Extensions Microsoft.HEIFImageExtension_8wekyb3… 1.0.43012.0
HEVC Video Extensions from Device Ma… Microsoft.HEVCVideoExtension_8wekyb3… 1.0.50361.0
Microsoft Edge Microsoft.MicrosoftEdge.Stable_8weky… 100.0.1185.50
Paint Microsoft.Paint_8wekyb3d8bbwe 11.2201.22.0
Power Automate Microsoft.PowerAutomateDesktop_8weky… 1.0.180.0
PowerShell Preview Microsoft.PowerShellPreview_8wekyb3d… 7.3.3.0
Snipping Tool Microsoft.ScreenSketch_8wekyb3d8bbwe 11.2201.12.0
Windows Security Microsoft.SecHealthUI_8wekyb3d8bbwe 1000.22000.1.0
Store Experience Host Microsoft.StorePurchaseApp_8wekyb3d8… 12109.1001.10.0
VP9 Video Extensions Microsoft.VP9VideoExtensions_8wekyb3… 1.0.50901.0
Web Media Extensions Microsoft.WebMediaExtensions_8wekyb3… 1.0.42192.0
Webp Image Extensions Microsoft.WebpImageExtension_8wekyb3… 1.0.42351.0
Microsoft Photos Microsoft.Windows.Photos_8wekyb3d8bb… 2021.21120.8011.0
Windows Calculator Microsoft.WindowsCalculator_8wekyb3d… 11.2201.4.0
Windows Camera Microsoft.WindowsCamera_8wekyb3d8bbwe 2022.2201.4.0
Notepad Microsoft.WindowsNotepad_8wekyb3d8bb… 11.2112.32.0
Microsoft Store Microsoft.WindowsStore_8wekyb3d8bbwe 22203.1401.26.0
Windows Terminal Microsoft.WindowsTerminal 1.12.10983.0 winget
Windows Package Manager Source (wing… Microsoft.Winget.Source_8wekyb3d8bbwe 2022.412.2240.845
Xbox TCUI Microsoft.Xbox.TCUI_8wekyb3d8bbwe 1.24.10001.0
Xbox Game Bar Microsoft.XboxGamingOverlay_8wekyb3d… 5.722.3302.0
Xbox Identity Provider Microsoft.XboxIdentityProvider_8weky… 12.85.31001.0
Phone Link Microsoft.YourPhone_8wekyb3d8bbwe 1.22032.179.0
Windows Web Experience Pack MicrosoftWindows.Client.WebExperienc… 421.20070.95.0
OBS Studio OBSProject.OBSStudio 27.2.4 winget
Microsoft OneDrive Microsoft.OneDrive 21.220.1024.0005 22.033.0213.0002 winget
Rockstar Games Launcher Rockstar Games Launcher 1.0.53.576
Rockstar Games Social Club Rockstar Games Social Club 2.1.3.2
Steam Valve.Steam 2.10.91.91 winget
3DMark Demo Steam App 231350 Unknown
Mail and Calendar microsoft.windowscommunicationsapps_… 16005.14326.20858.0
PowerToys (Preview) Microsoft.PowerToys 0.57.2 winget
Intel(R) Management Engine Components {1CEAC85D-2590-4760-800F-8DE5E91F370… 11.0.5.1192
Microsoft Visual C++ 2012 Redistribu… Microsoft.VC++2012Redist-x86 11.0.61030.0 winget
Microsoft Windows Desktop Runtime - … {3869e7e8-f986-44af-971d-504e4c9975d… 3.1.24.31129
Microsoft Visual C++ 2015-2019 Redis… {5bfc1380-fd35-4b85-9715-7351535d077… 14.22.27821.0
Microsoft Visual C++ 2015-2019 Redis… {6361b579-2795-4886-b2a8-53d5239b645… 14.22.27821.0
Microsoft Update Health Tools {6A2A8076-135F-4F55-BB02-DED67C8C693… 4.67.0.0
Microsoft Windows Desktop Runtime - … {73e5de3a-8f61-4a4a-ac84-0d7d5c9b9b5… 6.0.4.31115
Veeam Agent for Microsoft Windows {7796202E-3320-41ED-9A2C-14613AEED3D… 5.0.3.4708
Microsoft SQL Server 2012 Management… {7ED2561C-FBC2-421E-A2B5-C7BEFD62314… 11.4.7001.0
Intel(R) Serial IO {9FD91C5C-44AE-4D9D-85BE-AE52816B029… 30.63.1603.5
NVIDIA 3D Vision Driver 388.73 {B2FE1952-0186-46C3-BAEC-A80AA35AC5B… 388.73
NVIDIA Graphics Driver 388.73 {B2FE1952-0186-46C3-BAEC-A80AA35AC5B… 388.73
NVIDIA HD Audio Driver 1.3.36.6 {B2FE1952-0186-46C3-BAEC-A80AA35AC5B… 1.3.36.6
Microsoft SQL Server 2012 Express Lo… {C18B132E-4032-4425-826A-24B1CA9DFF0… 11.4.7001.0
Microsoft System CLR Types for SQL S… {CECCBAE9-1880-411E-9D28-8E562F6DAAE… 11.4.7001.0
Futuremark SystemInfo {DA53AC08-9CD0-4C02-840D-42506441CB4… 5.47.1064.0
Windows Subsystem for Linux WSLg Pre… {E04B0005-A349-4BCC-9662-CA0132007E1… 1.0.26
Microsoft Visual Studio Code Microsoft.VisualStudioCode 1.66.2 winget
Windows Subsystem for Linux Update {F8474A47-8B5D-4466-ACE3-78EAB3BF21A… 5.10.102.1
Microsoft Visual C++ 2012 Redistribu… Microsoft.VC++2012Redist-x64 11.0.61030.0 wingetAs you can see, most of the things on there are either preinstalled or by Microsoft, as is the thing I'm trying to install.
ItzLevvie
commented
2 years ago What about running winget source reset --force and then running winget source update with administrator privileges?
If that's all it takes to break winget then maybe make it more resilient?
There are various third-party applications that can sometimes break your OS files / registry entries into bits and pieces even if you never touched or never installed CCleaner before.
It'll also break more than just WinGet so other applications could be impacted without you knowing about it.
I'm actually not even sure if I wanna install whatever you linked there, I'm that cautious.
It's the exact same Download URL that you shared in your original post as part of your error logs but you can also run winget source reset --force to redeploy the source file.
Not sure what you mean. There isn't even a Store in Sandbox.
WinGet can be manually installed via the Add-AppxPackage command if there's an issue you want to reproduce so you don't realistically need the Microsoft Store to be installed in Windows Sandbox to use WinGet.
You could try to reproduce your issue there if you wanted to and check what the outcome is. I'm not able to do this because I cannot reproduce this issue.
If I need to resort to an in-place upgrade a week into a clean install and cautious usage then there is something seriously wrong and will break again a week after.
Not uncommon.
There was a user who blamed WinGet for breaking their OS when in theory it was caused by the user (https://github.com/microsoft/winget-cli/issues/1005) while other issues are related to CCleaner breaking OS installation.
Sometimes there's just a lot variables on how issues like this can happen because of how complex Windows is.
If you've already tried to redeploy the source file by running winget source reset --force and winget source update with administrator privileges but you're still seeing Access is denied. then I'm afraid that you'll have to do an in-place upgrade using an ISO image.
I'm not really that careful with my installation of Windows but I have yet to see anything break on my end even though I'm running Insider Preview builds of Windows 11.
Although you mentioned that it's a 1-week old installation, I'm more talking about a 5-minute old installation which I was able to achieve via Hyper-V using a VHDX file to provide you a quick PoC.
I don't know what exactly caused this issue other than the fact that it's definitely an issue on your end because Access is denied. is more or less impossible to achieve on a 5-minute old install of Windows 11.
github-account1111
commented
2 years ago Did you try reproducing on a fully up-to-date Windows install? I'm asking because it takes well over 5 minutes to get through all the post-install updates (as well as rebooting, usually several times), and updates often break things, in which case it should be looked at.
There are various third-party applications that can sometimes break your OS files / registry entries into bits and pieces even if you never touched or never installed CCleaner before.
I posted a list of everything installed above. They're all popular software. I installed all of it either via Store or winget itself. If winget distributes software that does what you're saying then maybe that, again, should be looked at.
ItzLevvie
commented
2 years ago Did you try reproducing on a fully up-to-date Windows install?
Yes I did.
I used the Windows 11 ISO (22000.1) and the Windows 11 VHDX (22000.613) from the build release share and I also downloaded the Windows 11 ISO from https://www.microsoft.com/en-us/software-download/windows11 but still unable to reproduce this issue.
Using the VHDX was faster than ISO because it already included the latest Cumulative Update (CU) and also skips most of the installation phase other than the OOBE for user name, password, etc. All that was left for me were Microsoft Defender Antivirus and .NET Framework 3.5 / 4.8 updates which installed quite fast using Windows Update, and even though it didn't require a reboot for those two updates, I ended up rebooting anyways.
Using the ISO did take longer than VHDX because it has to go through the installation phase then OOBE then OOBE installs a Cumulative Update (CU) then OOBE again but for username, password, etc. After that I have to install everything, such as 22000.613, in Windows Update and update all of the applications from the Microsoft Store.
These are pictures taken from the VM that used an ISO image which is also the same outcome for VHDX:
There's also a new optional update released today which seems to include a bug fix for MSIX but I don't know if that'll change anything: https://www.windowslatest.com/2022/04/26/windows-11-kb5012643-released-heres-everything-new-and-improved/
updates often break things, in which case it should be looked at.
It should be posted in Feedback Hub because the Windows Servicing & Delivery (WSD) team are the ones that manages the production builds of Windows 11 and the Feedback Hub is always being checked by various teams regardless of how many upvotes a particular issue gets.
WSD heavily prioritizes useful bug fixes, security fixes, and some features from the Windows Insider Preview builds into production builds of Windows 11.
If winget distributes software that does what you're saying then maybe that, again, should be looked at.
I'm sure the developers of those applications are already aware of that due to the amount of complaints they receive.
Also, No applicable installer found; see logs for more details. has been solved because of my pull request: https://github.com/microsoft/winget-pkgs/pull/58663.
I didn't show it in the VM because that application doesn't allow VMs to install it but it works fine on my PC running Dev Channel builds:
github-account1111
commented
2 years ago It should be posted in Feedback Hub
I would if they had a website. I'd post so much feedback..
Also just because you can't reproduce doesn't mean it's "on my end." There are so many things that could be at play including various settings (in Windows as well as winget) that could be causing this.
Using a "5 minute clean install" perpetually is not realistic either.
You're also running a way different winget version from me. Is it the default one from the Store?
Overall there could be so many other variables that are not "on my end" so I don't think such accusations are warranted or that the issue should be disregarded on that ground alone.
and I also downloaded Windows 11 from https://www.microsoft.com/en-us/software-download/windows11 but still unable to reproduce this issue
Did you download via Media Creation Tool? That's what I was using.
ItzLevvie
commented
2 years ago Using a "5 minute clean install" perpetually is not realistic either.
I guess my point here is that this shouldn't be happening to you regardless if it's a "5 minute clean install." or not.
If I cannot reproduce it under a "5 minute clean install" then I shouldn't be able to reproduce it under a 2-month-old dirty install or even a 1-year-old dirty install which is what I'm expecting and is what I'm seeing.
My 2-month-old and 1-year-old installs work completely fine with more than 30+ applications installed, though, those are running on Windows Insider Preview builds as I don't have any PCs running on production builds of Windows 11 other than pure virtual machines.
Using a clean (a.k.a. fresh) installation of Windows 11 from scratch on a virtual machine or on a separate partition alongside your affected OS is more than enough to find where the root cause is which is what I would do if I ever had this issue.
Also just because you can't reproduce doesn't mean it's "on my end." There are so many things that could be at play including various settings (in Windows as well as winget) that could be causing this.
Yes you're right that it can be caused by many things but it's hard to tell what exactly happened without you sysprepping your machine and sharing the sysprepped image to the public which obviously won't happen due to personal files, etc.
My demonstration was that it's just a Proof of Concept (PoC) to show you that the fault wasn't caused by WinGet and wasn't caused by the OS updates from various Cumulative Updates that you've installed. There was actually a Cumulative Update that broke some stuff, including WinGet and Windows Subsystem for Linux 2, but that was several months ago and has already been bug fixed. Full OS upgrades would also be a different type of situation but not when you went from RS5 (Windows 10) to 21H2 (Windows 11) via a clean install.
I'm also still using the same PC where I installed 1000+ apps to play around with WinGet packages and uninstalled all of them so that cluttered all of my drives, registry entries, etc. but still no issues here.
You're also running a way different winget version from me. Is it the default one from the Store?
It's the same one you're running.
Yours (WinGet): 1.2.10271 Mine (WinGet): 1.2.10271
Yours (App Installer): 1.17.10271.0 Mine (App Installer): 1.17.10271.0
This is listed in your original post:
This is my picture:
Version numbers do look the same to me, and yes, it's from the Microsoft Store.
I purposely didn't sign in with my personal Outlook email address because then I would get automatically upgraded from 1.2.10271 to 1.3.692-preview which isn't what I wanted.
Overall there could be so many other variables that are not "on my end" so I don't think such accusations are warranted or that the issue should be disregarded on that ground alone.
If other people were able to reliably reproduce this issue then I wouldn't of jumped into conclusions in the first place because the GitHub issue tracker and Feedback Hub would be filled with issues like this one which would obviously get the engineering team's attention and those issues would then get prioritized for a bug fix.
I can, of course, reproduce the issue if I changed the permissions for the %SystemRoot%\Temp or C:\Users\%USERNAME%\AppData\Local\Temp but since you said that the folder permissions are correct then I have no what's going on.
WinGet mostly downloads installers to C:\Users\%USERNAME%\AppData\Local\Temp for EXE and MSI but I believe MSIX / APPX files are downloaded to %SystemRoot%\Temp for installation as when I was downloading Ear Trumpet C:\Users\%USERNAME%\AppData\Local\Temp\WinGet\File-New-Project.EarTrumpet.2.1.10.0 was completely empty but when checking %SystemRoot%\Temp there's files related to WinGet's Ear Trumpet installation there.
Even if you've never touched those folders before, WinGet and other programs do, in fact, touch it but WinGet doesn't modify any folder permissions. If your folder permissions are incorrect then WinGet will tell you that in the logs. It might not be user friendly because it doesn't exactly tell you which folder is giving you Access is denied. but it's a start.
Rest of the stuff in WinGet is done purely by the installers. All WinGet does is run installers with silent switches. WinGet doesn't modify any local files right now—not until portable apps and zip support becomes a thing in the future which is coming soon—this is all done by installers.
That means WinGet doesn't play around with your %PATH% (for now) as that's currently the application you install's responsibility as well as making any modifications to your system which would require your consent for UAC elevation.
For what it's worth all that's happening on your side is that WinGet is failing to deploy the source.msix file due to the Access is denied. issue.
This isn't a network issue on Microsoft's side because it successfully downloaded the source.msix on your PC. If the source.msix file got corrupted during downloading then you'll get a different error because MSIX / APPX has anti-tamper built-in where AppxSignature.p7x or AppxBlockMap.xml checks the hash of all of the file contents in the source.msix file to ensure that it hasn't been tampered or corrupted during installation. If it doesn't match, it doesn't install.
Did you download via Media Creation Tool? That's what I was using.
Yes I did.
One of the ISOs were downloaded from https://www.microsoft.com/en-us/software-download/windows11.
Another one of the ISOs were downloaded from within the Media Creation Tool.
Regardless of which SKU I used the outcome will always be the same for me because the system OS files are still going to be the same as the only thing that's different there is licensing. This would be a different story if this was Home / Pro / Enterprise vs Server or LTSC because the installation methods for some areas are vastly different.
These are also not UUPdump ISOs as UUPdump doesn't create an ISO that's consistent to the official Windows 11 ISOs. I haven't used them in over 2 years when the easiest way is that I can grab whatever install media I want from the build release share ;)
(EDIT): Here's a picture from a "Standard account". WinGet2 is created via the Settings app and has no administrator privileges everything required a password but winget source update ran and deployed the latest source.msix file:
github-account1111
commented
2 years ago It's the same one you're running.
My bad, istg I saw a different version :D must'a been tired.
What should the permissions be for %SystemRoot%\Temp and %USERNAME%\AppData\Local\Temp?
Also, which app in https://github.com/microsoft/winget-cli/issues/2114#issuecomment-1108792210 changes permissions in those folders?
Are permission changes kept track of in any way by the OS?
github-account1111
commented
2 years ago Also I've come to the conclusion that the error only comes up occasionally, while other times the upgrade and install commands seem to go through just fine. Maybe the servers this stuff is fetched from are unstable?
ItzLevvie
commented
2 years ago What should the permissions be for %SystemRoot%\Temp and %USERNAME%\AppData\Local\Temp?
%SystemRoot%\Temp:
%USERNAME%\AppData\Local\Temp:
Also, which app in https://github.com/microsoft/winget-cli/issues/2114#issuecomment-1108792210 changes permissions in those folders?
I haven't had the time to dig into that yet.
If you're still able to reproduce the issue then maybe capture via Sysinternals' Process Monitor? That will allow you to see what's happening and whether it's a first-party application or a third-party application that's doing this.
It's as far as you'll get to debugging this issue without doing an in-place upgrade or trying to reproduce on a second partition with a fresh installation of Windows to check if it's a local issue, a client issue, or a server issue.
Are permission changes kept track of in any way by the OS?
I don't think so as Windows doesn't ship with any monitoring software that's similar to Process Monitor.
Maybe the servers this stuff is fetched from are unstable?
This isn't the case according to the logs that you posted.
There are 2 stages: 1) Download (cloud - requires internet) 2) Install (local - you can disconnect your internet and it'll still work)
Download works because of this:
2022-04-22 16:10:10.212 [CORE] Downloading to path: C:\Users\username\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix
2022-04-22 16:10:10.213 [CORE] Started applying motw to C:\Users\username\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 3
2022-04-22 16:10:10.218 [CORE] Finished applying motw
2022-04-22 16:10:10.218 [CORE] WinINet downloading from url: https://winget.azureedge.net/cache/source.msix
2022-04-22 16:10:10.261 [CORE] Download completed.Install fails because of this:
2022-04-22 16:10:10.270 [CORE] Deployment operation #0: Access is denied.
2022-04-22 16:10:10.270 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FF91C9B657A: (caller: 00007FF91C9B6C09) Exception(1) tid(3e24) A2C22CC0 Msg:[Operation failed: Access is denied.
2022-04-22 16:10:10.282 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\RepositorySource.cpp(53)\WindowsPackageManager.dll!00007FF91CB102B1: (caller: 00007FF91CA0AA56) LogHr(1) tid(3e24) A2C22CC0 Msg:[D:\a\_work\1\s\external\pkg\src\AppInstallerCommonCore\Deployment.cpp(54)\WindowsPackageManager.dll!00007FF91C9B657A: (caller: 00007FF91C9B6C09) Exception(1) tid(3e24) A2C22CC0 Msg:[Operation failed: Access is denied.I run preview builds of WinGet all the time so I see issues way earlier than most people.
I ran into issues with unstable servers (was really just the publishing pipelines playing around with the source.msix file) but that was fixed because a lot of people ran into that issue and the error is also completely different to what you're seeing.
github-account1111
commented
2 years ago Then why does it only work sometimes? Right now I'm not getting any errors, but earlier today I was. Here's the logs from right now for the upgrade command:
2022-05-03 14:59:56.482 [CORE] WinGet, version [1.2.10271], activity [{41D4F057-80FA-4F1F-8D3E-77037AEA3171}]
2022-05-03 14:59:56.482 [CORE] OS: Windows.Desktop v10.0.22000.652
2022-05-03 14:59:56.482 [CORE] Command line Args: "C:\Users\al\AppData\Local\Microsoft\WindowsApps\winget.exe" upgrade
2022-05-03 14:59:56.482 [CORE] Package: Microsoft.DesktopAppInstaller v1.17.10271.0
2022-05-03 14:59:56.483 [CORE] IsCOMCall:0; Caller: winget-cli
2022-05-03 14:59:56.488 [CLI ] WinGet invoked with arguments: 'upgrade'
2022-05-03 14:59:56.488 [CLI ] Found subcommand: upgrade
2022-05-03 14:59:56.488 [CLI ] Leaf command to execute: root:upgrade
2022-05-03 14:59:56.494 [CLI ] Executing command: upgrade
2022-05-03 14:59:56.494 [REPO] GetCurrentSourceRefs: Source named 'microsoft.builtin.desktop.frameworks' from origin Default is hidden and is dropped.
2022-05-03 14:59:56.494 [REPO] Default source requested, multiple sources available, adding all to source references.
2022-05-03 14:59:56.494 [REPO] Adding to source references msstore
2022-05-03 14:59:56.494 [REPO] Adding to source references winget
2022-05-03 14:59:56.495 [REPO] Source past auto update time [5 mins]; it has been at least 1026 mins
2022-05-03 14:59:56.495 [REPO] Source past auto update time [5 mins]; it has been at least 1026 mins
2022-05-03 14:59:57.081 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2022-05-03 14:59:57.082 [CORE] Found matching extension.
2022-05-03 14:59:57.087 [CORE] Downloading to path: C:\Users\al\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix
2022-05-03 14:59:57.088 [CORE] Started applying motw to C:\Users\al\AppData\Local\Temp\WinGet\Microsoft.Winget.Source_8wekyb3d8bbwe.msix with zone: 3
2022-05-03 14:59:57.092 [CORE] Finished applying motw
2022-05-03 14:59:57.092 [CORE] WinINet downloading from url: https://winget.azureedge.net/cache/source.msix
2022-05-03 14:59:57.492 [CORE] Download completed.
2022-05-03 14:59:57.493 [CORE] Starting AddPackage operation #0: file:///C:/Users/al/AppData/Local/Temp/WinGet/Microsoft.Winget.Source_8wekyb3d8bbwe.msix SkipSmartScreen: 1
2022-05-03 14:59:57.498 [CORE] Begin waiting for operation #0
2022-05-03 14:59:57.498 [CORE] Begin blocking for operation #0
2022-05-03 14:59:57.569 [CORE] Successfully completed #0
2022-05-03 14:59:57.571 [FAIL] D:\a\_work\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\PreIndexedPackageSourceFactory.cpp(301)\WindowsPackageManager.dll!00007FFC1CD46181: (caller: 00007FFC1CD4502A) LogHr(1) tid(447c) 80071130 Fast Cache data not found.
2022-05-03 14:59:57.588 [REPO] Multiple sources available, creating aggregated source.
2022-05-03 14:59:57.588 [REPO] Adding to aggregated source: msstore
2022-05-03 14:59:57.591 [REPO] Sending http GET request to: https://storeedgefd.dsx.mp.microsoft.com/v9.0/information
2022-05-03 14:59:57.660 [REPO] Response status: 200
2022-05-03 14:59:57.661 [REPO] Sending http GET request to: https://storeedgefd.dsx.mp.microsoft.com/v9.0/information
2022-05-03 14:59:57.701 [REPO] Response status: 200
2022-05-03 14:59:57.702 [REPO] Adding to aggregated source: winget
2022-05-03 14:59:57.712 [CORE] Examining extension: PFN = Microsoft.Winget.Source_8wekyb3d8bbwe, ID = IndexDB
2022-05-03 14:59:57.712 [CORE] Found matching extension.
2022-05-03 14:59:57.756 [REPO] Opening SQLite Index for ImmutableRead at 'C:\Program Files\WindowsApps\Microsoft.Winget.Source_2022.429.303.10_neutral__8wekyb3d8bbwe\Public\index.db'
2022-05-03 14:59:57.757 [SQL ] Opening SQLite connection: 'file:/C:/Program Files/WindowsApps/Microsoft.Winget.Source_2022.429.303.10_neutral__8wekyb3d8bbwe/Public/index.db?immutable=1' [1, 40]
2022-05-03 14:59:57.759 [REPO] Opened SQLite Index with version [1.3], last write [2022-04-28 22:03:31.000]
2022-05-03 14:59:57.848 [REPO] Creating PredefinedInstalledSource with filter [None]
2022-05-03 14:59:57.848 [REPO] Creating new SQLite Index [4294967295.4294967295] at ':memory:'
2022-05-03 14:59:57.848 [SQL ] Opening SQLite connection: ':memory:' [6, 0]
2022-05-03 14:59:57.924 [REPO] Examining ARP entries for Machine | X64
2022-05-03 14:59:57.945 [REPO] Examining ARP entries for Machine | X86
2022-05-03 14:59:57.962 [REPO] Examining ARP entries for User | X64
2022-05-03 14:59:58.241 [REPO] Opening SQLite Index for ReadWrite at 'C:\Users\al\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\StoreEdgeFD\installed.db'
2022-05-03 14:59:58.241 [SQL ] Opening SQLite connection: 'C:\Users\al\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\StoreEdgeFD\installed.db' [2, 0]
2022-05-03 14:59:58.245 [REPO] Opened SQLite Index with version [1.3], last write [2022-04-12 18:04:38.000]
2022-05-03 14:59:58.305 [REPO] Opening SQLite Index for ReadWrite at 'C:\Users\al\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db'
2022-05-03 14:59:58.305 [SQL ] Opening SQLite connection: 'C:\Users\al\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Microsoft.Winget.Source_8wekyb3d8bbwe\installed.db' [2, 0]
2022-05-03 14:59:58.308 [REPO] Opened SQLite Index with version [1.3], last write [2022-04-28 03:11:23.000]
2022-05-03 14:59:58.564 [REPO] Found multiple matches for installed package [{33d1fd90-4274-48a1-9bc1-97e33d9c2d6f}] in source [Microsoft.Winget.Source_8wekyb3d8bbwe] when searching for [Query:[none] Include:ProductCode='{33d1fd90-4274-48a1-9bc1-97e33d9c2d6f}'[Exact] Include:NormalizedNameAndPublisher='microsoftvisualc2012redistributable'+'microsoft'[Exact]]
2022-05-03 14:59:58.565 [REPO] Checking match with package id: Microsoft.VC++2012Redist-x86
2022-05-03 14:59:58.565 [REPO] Checking match with package id: Microsoft.VC++2012Redist-x64
2022-05-03 14:59:58.577 [REPO] Found multiple matches for installed package [{5bfc1380-fd35-4b85-9715-7351535d077e}] in source [Microsoft.Winget.Source_8wekyb3d8bbwe] when searching for [Query:[none] Include:ProductCode='{5bfc1380-fd35-4b85-9715-7351535d077e}'[Exact] Include:NormalizedNameAndPublisher='microsoftvisualcredistributable'+'microsoft'[Exact]]
2022-05-03 14:59:58.578 [REPO] Checking match with package id: Microsoft.VC++2015-2022Redist-x86
2022-05-03 14:59:58.579 [REPO] Checking match with package id: Microsoft.VC++2015-2022Redist-x64
2022-05-03 14:59:58.580 [REPO] Checking match with package id: Microsoft.VC++2015-2019Redist-x86
2022-05-03 14:59:58.580 [REPO] Checking match with package id: Microsoft.VC++2015-2019Redist-x64
2022-05-03 14:59:58.580 [REPO] Appropriate available package could not be determined
2022-05-03 14:59:58.586 [REPO] Found multiple matches for installed package [{6361b579-2795-4886-b2a8-53d5239b6452}] in source [Microsoft.Winget.Source_8wekyb3d8bbwe] when searching for [Query:[none] Include:ProductCode='{6361b579-2795-4886-b2a8-53d5239b6452}'[Exact] Include:NormalizedNameAndPublisher='microsoftvisualcredistributable'+'microsoft'[Exact]]
2022-05-03 14:59:58.587 [REPO] Checking match with package id: Microsoft.VC++2015-2022Redist-x86
2022-05-03 14:59:58.587 [REPO] Checking match with package id: Microsoft.VC++2015-2022Redist-x64
2022-05-03 14:59:58.588 [REPO] Checking match with package id: Microsoft.VC++2015-2019Redist-x86
2022-05-03 14:59:58.588 [REPO] Checking match with package id: Microsoft.VC++2015-2019Redist-x64
2022-05-03 14:59:58.589 [REPO] Appropriate available package could not be determined
2022-05-03 14:59:58.647 [REPO] Found multiple matches for installed package [{ca67548a-5ebe-413a-b50c-4b9ceb6d66c6}] in source [Microsoft.Winget.Source_8wekyb3d8bbwe] when searching for [Query:[none] Include:ProductCode='{ca67548a-5ebe-413a-b50c-4b9ceb6d66c6}'[Exact] Include:NormalizedNameAndPublisher='microsoftvisualc2012redistributable'+'microsoft'[Exact]]
2022-05-03 14:59:58.648 [REPO] Checking match with package id: Microsoft.VC++2012Redist-x64
2022-05-03 14:59:58.648 [REPO] Checking match with package id: Microsoft.VC++2012Redist-x86
2022-05-03 14:59:58.708 [CLI ] Leaf command succeeded: root:upgradeOnce it starts erroring out again, I'll make sure to get the logs. In regard to permissions, second one looks the same, first one, not really:
ItzLevvie
commented
2 years ago Then why does it only work sometimes?
A variety of reasons but it has nothing to do with server side.
Only way you'll be able to tell is to use Process Monitor running in the background and then trying to repeoduce the issue which should tell you what process is accessing that path.
^ It'll also be able to tell whether Microsoft Defender is playing around with it which can happen sometimes.
If you think it's happening server-side then you should capture logs via Fiddler but for this you'll need to be able to reproduce consistently as Fiddler will prevent you from connecting to certain websites due to MITM.
github-account1111
commented
2 years ago I've attached the procmon logfile. Logfile.CSV As soon as I started getting the error again I started a capture and ran the winget command three times. I aimed procmon at the two temp dirs specifically.
Update: Here it went from being inaccessible back to working in a span of minutes:
I didn't actually do anything differently, so I doubt it's on my end.
ItzLevvie
commented
2 years ago I aimed procmon at the two temp dirs specifically.
I don't see any issue there but I also forgot one more path and that's C:\Program Files\WindowsApps
What about running Get-AppxLog in Windows PowerShell once you're able to reproduce the issue? It'll be similar to the WinGet logs but more verbose and focused on the APPX / MSIX deployment.
I didn't actually do anything differently
Whether or not you're able to reproduce it consistently or periodically have you tried to do an in-place upgrade to solve this yet? It will replace your system OS files with fresh ones.
Even if you're only running first-party apps and that your install is less than a month old you should still do an in-place upgrade. It's an alternative option for you to explore.
so I doubt it's on my end.
Just so you know I wouldn't be commenting here if it wasn't a local issue because I could leave that up to the WinGet engineering team to solve ;)
Most (not all of them) of the "Access is denied." issues in this repository were regarded as a local issue and that's to be expected as these "Access is denied." errors cannot be easily solved via an update to WinGet or App Installer.
^ This (above) could consist of:
I never ran into issues with my installation of Windows 10 / Windows 11 so I'm unable to expand on "a lot more that I'm missing here." but this issue still seems to be a local issue for you which means that if it's not a server-side issue and if it's not a client-side issue then you may have already gotten your answer here which is why I suggested you to do an in-place upgrade first in https://github.com/microsoft/winget-cli/issues/2114#issuecomment-1108530693 and then see if you're still able to reproduce it.
WinGet also entered GA in May 2021 which means a lot of people have started using WinGet between May 2021 and May 2022 and there hasn't been an "Access is denied." issue that isn't a local issue.
^ https://github.com/microsoft/winget-cli/issues/1848 required an in-place upgrade to solve that and the user isn't seeing that issue anymore.
If you're still able to reproduce this when you've done an in-place upgrade then the issue would be caused by whatever changes that's been done to your OS.
If you're still able to reproduce this on a separate disk partition or on a virtual machine then it's an OS issue which you should report to the Windows Feedback Hub.
github-account1111
commented
2 years ago I'd rather do a clean install than the neither-here-nor-there "solution" that's an in-place upgrade. With the former I can at least get back to a usable OS state fairly quickly, whereas in case of the latter I'm left guessing or digging through files and settings checking what was reverted to default and what wasn't.
More importantly though, why would I do an in-place upgrade? The problem will just return after a week because I don't treat the OS as a dumping ground, so everything I have installed I actually need on a regular basis.
company policies (contact your employer about this)
Do you happen to know which policies are known to cause this? I think this could be it.
I suspect that even when it's not throwing the error it's still not working.
The upgrade command has only been showing OneDrive for the past two weeks.
github-account1111
commented
2 years ago Just to update, the upgrade command has only been showing OneDrive for the past month:
PS C:\Users\al> winget source list
Name Argument
-----------------------------------------------------
msstore https://storeedgefd.dsx.mp.microsoft.com/v9.0
winget https://winget.azureedge.net/cache
PS C:\Users\al> winget source update
Updating all sources...
Updating source: msstore...
Done
Updating source: winget...
██████████████████████████████ 3.76 MB / 3.76 MB
Done
PS C:\Users\al> winget upgrade
Name Id Version Available Source
------------------------------------------------------------------------------
Microsoft OneDrive Microsoft.OneDrive 21.220.1024.0005 22.065.0412.0004 winget
1 upgrades available.
PS C:\Users\al> winget source reset --force
Resetting all sources...Done
PS C:\Users\al> winget upgrade
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
Name Id Version Available Source
------------------------------------------------------------------------------
Microsoft OneDrive Microsoft.OneDrive 21.220.1024.0005 22.065.0412.0004 winget
1 upgrades available.It doesn't even throw a warning anymore, just doesn't list anything new, even though it successfully updates and resets sources. My VSCode is still on version 1.67.0. There've been 2 versions in the stable channel since then. Other packages have probably also seen updates, but not according to winget! According to winget, OneDrive is the only thing that ever gets updates.
github-account1111
commented
2 years ago Another update: Now it's showing a new thing:
> winget upgrade
Name Id Version Available Source
-----------------------------------------------------------------------------------------------------------------------
Microsoft OneDrive Microsoft.OneDrive 21.220.1024.0005 22.065.0412.0004 winget
Microsoft Visual C++ 2015-2019 Redistributa… Microsoft.VC++2015-2019Redist-x64 14.29.30037.0 14.29.30139.0 winget
2 upgrades available.Every other package upgrade (e.g. VSCode, PowerToys, Docker) is still ignored. So it is able to fetch and show some (very select) new upgrades. How it decides on what to show and what to ignore I have no idea.
ItzLevvie
commented
2 years ago Do you happen to know which policies are known to cause this?
I've no idea as I've never tinkered around with any policies as most of the policies on my device are pretty much set up automatically via Azure Active Directory (AAD).
If this is actually a corporate device then it might be best to contact your employer about it since they might have custom policies in place which are not on Windows by default. This will also be the same for in-place upgrades and fresh installation of Windows as those policies will be re-applied.
I'm afraid that you're pretty much stuck here encountering the same issue with no way to solve this other than doing the above (or wait for the next feature update for Windows 11 which will force you do to an in-place upgrade) so I wouldn't be surprised if you're still going run into this issue one year later which is why it's best for you to make the decision now rather than waiting magically to fix itself.
If you're still running into this issue then Scoop (focuses on portable apps) or Chocolately (similar to WinGet but more powerful than WinGet) are good alternatives to WinGet while you end up getting it fixed.
So it is able to fetch and show some (very select) new upgrades.
Yes and that's because you're only running into this issue periodically and not all the time.
WinGet's source.msix is cached on your PC and it's around ~2 weeks old which is why you're seeing newer updates.
So you'll have to give it some time to update. Most people should see it update every 5 minutes (which is the default) when running winget list or winget search but for you it'll take a few days or even a few weeks due to this issue.
AnonymousWP
commented
2 years ago I'm still having this issue and now I can't even fix it by myself anymore. What I've tried:
winget source reset --force
winget source update (it doesn't even update the source: Updating source: winget... Cancelled
I also tried updating to the newest version of Winget CLI, as well as re-installing, but that solves it only for a temporary period of time. On my laptop it works fine, but doesn't on my desktop.
Edit: now I just tried it again and it works. It's like sometimes the winget source is down or something, but that's odd, cause I don't have this issue on my laptop.
NoSubstitute
commented
2 years ago Here's an issue showing that winget apparently is having all kinds of problems right now. https://github.com/microsoft/winget-cli/issues/1656
NoSubstitute
commented
2 years ago winget CDN should be fine now.
stephengillie
commented
1 year ago This might be two non-overlapping errors.
Failed in attempting to update the source: winget does indiciate Winget failed to update the Winget source, which would be the now hopefully resolved Winget CDN issues. Winget is able to recover from this and continue.No applicable installer found seems to refer to the mismatch between the --scope machine specified in the command, and the scope: Unknown from the manifest. 2022-04-22 16:10:12.804 [CLI ] Starting installer selection.
2022-04-22 16:10:12.804 [CLI ] Installer [X64,exe,Unknown,] not applicable: Installer scope does not match required scope: Unknown != Machine
2022-04-22 16:10:12.804 [CLI ] Installer [X86,exe,Unknown,] not applicable: Installer scope does not match required scope: Unknown != Machine
2022-04-22 16:10:12.804 [CLI ] Installer [Arm64,exe,Unknown,] not applicable: Installer scope does not match required scope: Unknown != Machine
2022-04-22 16:10:12.804 [CLI ] Installer [Arm64,exe,Unknown,] not applicable: Machine is not compatible with Arm64
2022-04-22 16:10:12.805 [CLI ] Terminating context: 0x8a150010 at D:\a\_work\1\s\external\pkg\src\AppInstallerCLICore\Workflows\InstallFlow.cpp:74
geekyBoogiepop
commented
1 year ago I'm experiencing the same issue right now. I can't even download source.msix manually. I've been trying to update my software for a week now.
rkeithhill-keysight
commented
1 year ago I'm also experiencing this issue.
Update: Updating from 1.3 to 1.4 seems to have resolved the issue for me.
jaysonsantos
commented
1 year ago My way of ending up with this issue was by having new apps installed into a new disk on D:, then the disk fried, and I had it removed and, after that, winget didn't work anymore.
Brief description of your issue
Unable to install a package:
Logs:
Steps to reproduce
Try to install a package.
Expected behavior
Package gets installed
Actual behavior
Error.
Environment