winget-cli
winget-cli copied to clipboard
microsoft
Winget on fresh Windows 11 for Arm 64 install does not work and cannot be updated through the release .msix
Brief description of your issue
I am unable to update sources, install packages, or even install the most recent winget release .msixbundle on a fresh install of Windows 11 Pro Arm 64 running on a VM on an M1 Mac under Parallels. This seems to be closely related to (or a duplicate of) a number of other issues, but I thought I would open this because of the Arm 64 issue, and because I have logs to attach.
Steps to reproduce
winget source update
Add-AppxPackage https://github.com/microsoft/winget-cli/releases/latest/download/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle
Expected behavior
For either the initial winget command to succeed or fail with an error message, and for the installation of the .msixbundle to succeed.
Actual behavior
winget source update fails weirdly, with no output but a stopped spinner and the following PS prompt coloured blue, the same as the spinner.
Add-AppxPackage ... fails with an error about resources being in use:
Add-AppxPackage : Deployment failed with HRESULT: 0x80073D02, The package could not be installed because resources it
modifies are currently in use.
error 0x80073D02: Unable to install because the following apps need to be closed
Microsoft.DesktopAppInstaller_1.17.10691.0_arm64__8wekyb3d8bbwe.
Environment
PS C:\Users\...> winget --info
Windows Package Manager v1.2.10691
Copyright (c) Microsoft Corporation. All rights reserved.
Windows: Windows.Desktop v10.0.22631.2792
Package: Microsoft.DesktopAppInstaller v1.17.10691.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
Logs related to the failure of the initial Windows 11 winget:
WinGet-2023-12-12-17-23-51.554.log WPM-2023-12-12-14-19-12.715.log WPM-2023-12-12-17-20-29.341.log
Output from Add-AppxPackage:
PS C:\Users\matt> Add-AppxPackage https://github.com/microsoft/winget-cli/releases/latest/download/Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle
Add-AppxPackage : Deployment failed with HRESULT: 0x80073D02, The package could not be installed because resources it
modifies are currently in use.
error 0x80073D02: Unable to install because the following apps need to be closed
Microsoft.DesktopAppInstaller_1.17.10691.0_arm64__8wekyb3d8bbwe.
NOTE: For additional information, look for [ActivityId] fd8de5a3-2cfe-0000-8146-90fdfe2cda01 in the Event Log or use
the command line Get-AppPackageLog -ActivityID fd8de5a3-2cfe-0000-8146-90fdfe2cda01
At line:1 char:1
+ Add-AppxPackage https://github.com/microsoft/winget-cli/releases/late ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (https://github....bbwe.msixbundle:String) [Add-AppxPackage], Exception
+ FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand
If I install VisualStudio Community 2022 through the Store app, after installation is complete the command line winget then functions correctly, so presumably the updated packages are installed in a different order or manner. Unfortunately, what I wanted to use winget for was to install VS 2022 and other project dependencies from a configuration .yaml...
Based on what I see here, I expect WinGet is failing to update the source due to its inability to connect to the CDN:
- #3652
The Add-AppxPackage seems to fail because it's waiting for the source update to complete.
If the first action taken on the OS is to update "App Installer" via the Microsoft Store, or to install WinGet from the GitHub releases, I would expect that to work.
We're still working on a few of these "chicken and egg" scenarios to get WinGet updated as part of the OS bootstrapping process without the expected ~15-minute delay after first login.
Based on what I see here, I expect WinGet is failing to update the source due to its inability to connect to the CDN:
That's what I thought - but I thought you might want the logs, too.
The Add-AppxPackage seems to fail because it's waiting for the source update to complete.
If the first action taken on the OS is to update "App Installer" via the Microsoft Store, or to install WinGet from the GitHub releases, I would expect that to work.
I just reset my VM back to a snapshot from the earliest point after setup has finished and Windows been activated, and running Add-AppxPackage did not work then either.
We're still working on a few of these "chicken and egg" scenarios to get WinGet updated as part of the OS bootstrapping process without the expected ~15-minute delay after first login.
Interestingly, looking at the logs I can see that when I attempted to install the .msixbundle after the reset, I had not run any winget commands at all, but Windows Package Manager had attempted to update itself (I presume the 15 minutes having expired). There was a Windows Package Manager Service process running that I hadn't started manually. Once I killed that, running the Add-AppxPackage completed fine. Is it possible that the attempt to update itself is suffering from the CDN problem, but leaving a hanging process that, in turn, prevents manual installation of the updated package?
I presume that the act of installing VS Community from the MS Store forces that hung self-updating WPM process to die, because it (VS) wants to update it too.
I had this exact same issue on a new install of W11. Only thing that worked was ending the Windows Package Manager Service process that was still running for some reason.
Has anyone found a work around? Hitting this same issue but do not have any Windows Package Manager Service process running
