[BUG] WinGet search/list fails on ARM64 after COM activation fails

[Zaptorg]

Please confirm these before moving forward

• I have searched for my issue and have not found a work-in-progress/duplicate/resolved issue.
• I have tested that this issue has not been fixed in the latest (beta or stable) release.
• I have checked the FAQ section for solutions.
• This issue is about a bug (if it is not, please use the correct template).

UniGetUI Version

2026.2.2

Windows version, edition, and architecture

Windows 11 Pro 25H2 26200.8655 ARM

Describe your issue

On Windows ARM64, WinGet is correctly detected by UniGetUI (found via winget.exe, CLI version reachable, winget list/winget search work fine from a normal terminal), and UniGetUI itself confirms in the manager-loaded log that WinGet is "enabled and ready to go". However, no WinGet results ever appear when searching for or listing packages inside UniGetUI, on this machine only — the exact same UniGetUI version works fine with WinGet on an x64 PC.

From the logs, two things happen in sequence:

The native WinGet COM activation fails with REGDB_E_CLASSNOTREG (class not registered), both for the packaged and the lower-trust activation attempts. UniGetUI correctly falls back to WinGetCliHelper (CLI-parsing mode) as a result.
However, WinGetCliHelper itself then throws System.InvalidOperationException: Cannot start process because a file name has not been provided when calling FindPackages_UnSafe, GetInstalledPackages_UnSafe, and GetAvailableUpdates_UnSafe — even though the WinGet executable path was correctly detected and logged just moments earlier (C:\Users<Users>\AppData\Local\Microsoft\WindowsApps\winget.exe). This suggests ProcessStartInfo.FileName ends up empty somewhere inside WinGetCliHelper specifically on this fallback path, distinct from whatever field populated the manager-detection log.

The automatic AttemptFastRepair() triggers but does not fix the issue, and reconnecting to the COM server fails again with "the active backend is not native WinGet."

Steps to reproduce the issue

1. Install/run UniGetUI 2026.2.2 on a Windows on ARM64 machine.
2. Search for any package or open the "Installed" / "Updates" tab.
3. WinGet never returns any result, while every other manager (Scoop, Pip, Chocolatey, PowerShell/PowerShell7) works normally.

UniGetUI Log

[12/07/2026 10:12:02] Packaged WinGet COM activation failed (Retrieving the COM class factory for component with CLSID {C53A4F16-787E-42A4-B304-29EFFB4BF597} failed due to the following error: 80040154 Classe non enregistrée (0x80040154 (REGDB_E_CLASSNOTREG)).), attempting lower-trust activation...
[12/07/2026 10:12:02] Lower-trust WinGet COM activation failed (0x80040154: Class not registered).
[12/07/2026 10:12:02] Native WinGet helper is unavailable on this machine (0x80040154: Class not registered)
[12/07/2026 10:12:02] WinGet will resort to using WinGetCliHelper()
[12/07/2026 10:12:02] Winget is enabled and was found on C:\Users\<users>\AppData\Local\Microsoft\WindowsApps\winget.exe

...

[12/07/2026 10:12:09] Manager WinGet failed to find packages with exception InvalidOperationException: Cannot start process because a file name has not been provided.
[12/07/2026 10:12:09] Manager WinGet failed to list installed packages with exception InvalidOperationException: Cannot start process because a file name has not been provided.
[12/07/2026 10:12:09] Since this was the first attempt, Winget.AttemptFastRepair() will be called and the procedure will be restarted
[12/07/2026 10:12:09] Attempted to reconnect to COM Server but the active backend is not native WinGet.
[12/07/2026 10:12:09] Error finding packages on manager Winget with query localsend
[12/07/2026 10:12:09] Error finding installed packages on manager Winget
[12/07/2026 10:12:09] System.InvalidOperationException: Cannot start process because a file name has not been provided.
   at System.Diagnostics.Process.Start()
   at UniGetUI.PackageEngine.Managers.WingetManager.WinGetCliHelper.FindPackages_UnSafe(String query)
   at System.Threading.Tasks.Task`1.InnerInvoke()
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
--- End of stack trace from previous location ---
   at System.Threading.ExecutionContext.RunFromThreadPoolDispatchLoop(Thread threadPoolThread, ExecutionContext executionContext, ContextCallback callback, Object state)
   at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread)
[12/07/2026 10:12:09] System.InvalidOperationException: Cannot start process because a file name has not been provided.
   at System.Diagnostics.Process.Start()
   at UniGetUI.PackageEngine.Managers.WingetManager.WinGetCliHelper.GetInstalledPackages_UnSafe()
   at UniGetUI.PackageEngine.Managers.WingetManager.WinGet.GetInstalledPackages_UnSafe()
[12/07/2026 10:12:09] Manager WinGet failed to list available updates with exception InvalidOperationException: Cannot start process because a file name has not been provided.
[12/07/2026 10:12:10] Error finding updates on manager Winget
[12/07/2026 10:12:10] System.InvalidOperationException: Cannot start process because a file name has not been provided.
   at System.Diagnostics.Process.Start()
   at UniGetUI.PackageEngine.Managers.WingetManager.WinGetCliHelper.GetAvailableUpdates_UnSafe()
   at UniGetUI.PackageEngine.Managers.WingetManager.WinGet.GetAvailableUpdates_UnSafe()

Package Managers Logs

I no longer have the logs from before the fix.

Relevant information

winget list, winget search, winget upgrade all work correctly from a plain PowerShell/CMD terminal on this same machine.

Running the following in an elevated PowerShell and restarting UniGetUI fixes the issue:

'powershellGet-AppxPackage Microsoft.DesktopAppInstaller | Reset-AppxPackage'

Screenshots and videos

No response

[GabrielDuf]

Hi, thanks for the logs — they pinpoint the issue.

Two things are happening:

1. COM activation fails on your machine (0x80040154, REGDB_E_CLASSNOTREG). The Microsoft.DesktopAppInstaller COM server isn't registered, which is why Reset-AppxPackage fixes it. In this case, UniGetUI is supposed to fall back to the winget.exe CLI.
2. There was also a bug in the CLI fallback, which started the process with an empty file name (Cannot start process because a file name has not been provided). As a result, search, list, and update operations failed even though winget.exe was detected.

This has already been fixed in #5066 (not yet released). Once that release is available, UniGetUI should use the CLI fallback correctly even without the Reset-AppxPackage workaround.

Could you try the next release once it's available and let us know if the issue is resolved?