Skip to content

Winget.exe reparse links in %appdatalocal%\Microsoft\WindowsApps point to inconsistent and incorrect targets #5291

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Cenedd opened this issue Mar 12, 2025 · 1 comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation.

Comments

@Cenedd
Copy link

Cenedd commented Mar 12, 2025

Brief description of your issue

winget.exe reparse links in %appdatalocal%\Microsoft\WindowsApps point to inconsistent and incorrect targets.

Steps to reproduce

I've been using winrs to remote shell onto an assortment of remote Windows 10/11 Pro PCs.
Some had winget already installed. Those that didn't, I installed with
Add-AppxPackage -RegisterByFamilyName -MainPackage Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
Returning at a later time to use winget to install another program and winget fails to run

Expected behavior

Winget to run as normal

Actual behavior

Powershell:
Program 'winget.exe' failed to run: The system cannot find the path specifiedAt line:1 char:1
CMD:
The system cannot find the file %localappdata%\Microsoft\WindowsApps\winget.exe.

It appears that there are two copies of winget.exe as zero byte reparse links:
%localappdata%\Microsoft\WindowsApps\winget.exe
%localappdata%\Microsoft\WindowsApps\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\winget.exe
The first of these is in the 'path' environment variable and is what is returned by (get-command winget).path

Querying the target of these reparse points using
fsutil reparsepoint query "%localappdata%\Microsoft\WindowsApps\winget.exe"
reveals that the first points to
c:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.24.25199.0_x64__8wekyb3d8bbwe\winget.exe
and the second to
c:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_1.25.339.0_x64__8wekyb3d8bbwe\winget.exe
The first of these paths doesn't exist - presumably it has been superceded.

Specifying to run
%localappdata%\Microsoft\WindowsApps\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\winget.exe
works fine, it appears to be just the reparse point that it pointing to the wrong location. It doesn't seem to be possible to just copy one in place of the other.

Could you please advise how to resolve the issue with incorrectly targeted reparse points and also whether there is a known cause or something to avoid that may have caused this issue.

Many thanks,
Gareth

Environment

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

Windows: Windows.Desktop v10.0.22631.4890
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.25.339.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
@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Triage Issue need to be triaged label Mar 12, 2025
@denelon
Copy link
Contributor

denelon commented Mar 13, 2025

This looks like it's related to:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation.
Projects
None yet
Development

No branches or pull requests

2 participants