Winget doesn't properly cleanup unused `Microsoft.Winget.Source` Appx Packages

[Skyb0rg007]

Brief description of your issue

> Get-ChildItem -Path $env:ProgramFiles\WindowsApps -Filter 'Microsoft.Winget.Source_*_neutral__8wekyb3d8bbwe' | Measure-Object | Select-Object -Property Count

Count
-----
  452

> Get-AppxPackage -AllUsers | Where-Object { $_.Name -like 'Microsoft.Winget.Source*' } | Measure-Object | Select-Object -Property Count

Count
-----
    1

> Get-AppxPackage -AllUsers | Where-Object { $_.Name -like 'Microsoft.Winget.Source*' } | Select-Object -Property InstallLocation

InstallLocation
---------------
C:\Program Files\WindowsApps\Microsoft.Winget.Source_2025.722.604.24_neutral__8wekyb3d8bbwe

Steps to reproduce

This occurred over the course of using winget, so I'm not sure the ultimate cause.

Expected behavior

There should be exactly one Appx package for Microsoft.Winget.Source in my WindowsApps directory.

Actual behavior

There are 452 Appx packages for Microsoft.Winget.Source in my WindowsApps directory, each with a different date. The older versions are not registered with Appx and so they cannot be removed without SYSTEM permissions.

Environment

[winget --info]
Windows Package Manager v1.11.400
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.26100.4652
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.26.400.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                        Enabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

[Trenly]

• Related to It seems that there are many outdated source folders in the C:\Program Files\WindowsApps directory. #5522 (comment)

cc @JohnMcPMS

[Skyb0rg007]

This is related, but the answer (don't delete them because the folders are under management of Windows) is not correct, as seen by the fact that Get-AppxPackage doesn't list the outdated directories.

[jean3x7]

# Run this as Administrator on powershell, it will delete all Microsoft.Winget.Source folders in C:\Program Files\WindowsApps except the active one

# Define base path
$basePath = "C:\Program Files\WindowsApps"

# Get the install location of the active Microsoft.Winget.Source package
$excludePath = (Get-AppxPackage -AllUsers | Where-Object { $_.Name -like 'Microsoft.Winget.Source*' }).InstallLocation

# Extract just the folder name to compare
$excludeFolder = Split-Path $excludePath -Leaf

# Get all matching folders in WindowsApps
$folders = Get-ChildItem -Path $basePath -Directory -Force |
    Where-Object {
        $_.Name -like 'Microsoft.Winget.Source_*_neutral__8wekyb3d8bbwe' -and $_.Name -ne $excludeFolder
    }

# Loop through and delete the folders
foreach ($folder in $folders) {
    $fullPath = $folder.FullName
    Write-Host "Processing: $fullPath"

    # Take ownership
    takeown /f "$fullPath" /r /d Y | Out-Null

    # Grant full control to current user
    $acl = Get-Acl $fullPath
    $user = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name
    $accessRule = New-Object System.Security.AccessControl.FileSystemAccessRule(
        $user, "FullControl", "ContainerInherit,ObjectInherit", "None", "Allow"
    )
    $acl.SetAccessRule($accessRule)
    Set-Acl $fullPath $acl

    # Delete the folder
    Remove-Item -Path $fullPath -Recurse -Force -Confirm:$false
    Write-Host "Deleted: $fullPath" -ForegroundColor Green
}

Write-Host "Done. Excluded: $excludeFolder" -ForegroundColor Yellow

[phtnnz]

Same thing on my Win 10 system. I used 7-zip file manager (7FM.exe) run as adminstrator to delete all the old versions under WindowsApps, which accumulated to 12 GB.

[CreeperKong]

Same thing on my Win 10 system. I used 7-zip file manager (7FM.exe) run as adminstrator to delete all the old versions under WindowsApps, which accumulated to 12 GB.

Me too

[JustMyGithub]

This is not the only part of inproper cleanup, I think:

Windows App Runtime DDLM 5001.275.500.0-x6
Windows App Runtime DDLM 5001.275.500.0-x8
Windows App Runtime DDLM 8000.675.1142.0-x6
Windows App Runtime DDLM 8000.675.1142.0-x8
MSIX\Microsoft.WindowsAppRuntime.1.7_7000.744.1258.0_x64__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.7_7000.744.1258.0_x86__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.5_5001.373.1736.0_x86__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.5_5001.373.1736.0_x64__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.6_6000.519.329.0_x64__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.6_6000.519.329.0_x86__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.8_8000.642.119.0_x64__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.8_8000.675.1142.0_x64__8wekyb3d8bbwe

It looks like many components bloat the system by keeping each and every old version. Also I could not find a solution to "hey windows, remove all old versions that are not required by an installed WindowsApp anymore". To me it looks like an inproper design and I am not sure how much this has to do with winget(-cli) which is why I ask in this related issue before creating a issue for that.

[DrusTheAxe]

It looks like many components bloat the system by keeping each and every old version

That would be incorrect. Look closer...

> Windows App Runtime DDLM 5001.275.500.0-x6
> Windows App Runtime DDLM 5001.275.500.0-x8
> Windows App Runtime DDLM 8000.675.1142.0-x6
> Windows App Runtime DDLM 8000.675.1142.0-x8

Those are Windows App SDK's Dynamic Dependency Lifetime Manager packages and their package Name are unique

• DDLM package Name = Microsoft.WinAppRuntime.DDLM.<Version>-<ShortArchitecture>[-ShortVersionTag]
• In winappsdk 1.x the first part of <Version> = 5001 and 8000 - those 5 and 8 mean it's winappsdk release 1.5 and 1.8.
• The last part <ShortArchitecture> = x6 and x8` - means it's x64 and x86
  Thus 2 releases of winappsdk, each with 2 architectures. These are unique package Names so no bloat.¹

¹ WinAppSDK 1.x's versioning scheme treats each major.minor as distinct and unrelated. Thus 1.5 and 1.8 are independent releases; 1.8 is NOT a drop-in backwards compatible runtime update for 1.5. If you build with 1.5 you need to run with 1.5; 1.8 is irrelevant to you (and vice versa).

[DrusTheAxe]

MSIX\Microsoft.WindowsAppRuntime.1.7_7000.744.1258.0_x64__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.7_7000.744.1258.0_x86__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.5_5001.373.1736.0_x86__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.5_5001.373.1736.0_x64__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.6_6000.519.329.0_x64__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.6_6000.519.329.0_x86__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.8_8000.642.119.0_x64__8wekyb3d8bbwe
MSIX\Microsoft.WindowsAppRuntime.1.8_8000.675.1142.0_x64__8wekyb3d8bbwe

These are package full names and show a similar pattern. WinAppSDK's Framework package Name = Microsoft.WindowsAppRuntiume.<major>.<minor>. I see packages for 1.5, 1.6, 1.7 and 1.8 which are all distinct releases, and each has x86 and x64 flavors. Thus 2 unique architectures for each of 4 unique releases, so none of these are redundant.