[BUG] WinGet functionality inside UniGetUI seems to be corrupted or broken since installing UniGetUI v3.1.4 beta 1 #3055
Comments
ZPNRG
changed the title
|
Please run the following commands in powershell: |
|
I first started to run the "Install-Module Microsoft.WinGet.Client" in a non-eleveated Powershell window, but it said it needed admin privileges. So, I opened an admin-level Powershell window and ran both lines in succession. Nothing appeared to happen. This is what I saw:
However, apparently, the Microsoft Store version of WinGet was installed. I see this in the sources:
This didn't fix anything. I wasn't getting the "WinGet malfunction detected" message, but UniGetUI was also still not finding any updates. However, once I re-enabled the "Enable the automatic WinGet troubleshooter" option, the "WinGet malfunction detected" message returned and UniGetUI still isn't finding any available updates (that I know there are). |
|
|
|
--list doesn't appear to be a valid switch/option. From an admin Powershell window, "winget list" works fine and comes back with a list of maybe 70-80 apps installed on the system. Here is a small sample of the first few listed:
|
|
Now, after running this command, please test UniGetUI again |
|
Okay. Nothing has changed. Upon lauching UniGetUI and checking for updates, I immediately got the "WinGet malfunction detected" message and no updates were found. Here is what I wonder... For probably 15 years or so, I have run my primary Windows account as a Standard (non-admin) account. I still do and I just deal with UAC and perform the necessary admin authentication as needed for various tasks. So, when I open a (non-admin) Windows Powershell window and run "winget list", I get this:
As I said above earlier, if I open an admin (elevated) Powershell window, then "winget list" works fine and comes back with a long list of installed apps. However, since I started using WinGetUI (now UniGetUI) in June 2023, I've always been running it 100% of the time from my Standard (non-admin) Windows account. I do install UniGetUI to work for all users, but I never use it from the Windows admin account. So, if Winget is having a problem from a regular (non-admin) Powershell command line launched from my Standard Windows account, then I wouldn't think UniGetUI would be able to work when it is running in my Standard Windows account unless UniGetUI is somehow getting around that behind the scenes. I wonder if I need to delete both sources and then just re-install the original source I was using (https://cdn.winget.microsoft.com/cache). Granted, maybe you have seen better results with UniGetUI using the MSStore version. |
|
@ZPNRG |
|
@DrStrange Okay. I'll look into it. What is strange is that something must have changed with me installing UniGetUI 3.1.4 beta 1 that introduced this or the dormant bug was brought to the surface. Nothing has changed on my PC as far as permissions, etc. Geez, I haven't reinstalled Windows in a couple of years. Now, that said, maybe Windows is getting "creaky" and a Windows update or something else screwy happened about the same time as I updated to UniGetUI 3.1.4 beta 1. |
|
I had the same issue and ran the suggested commands in powershell: I no longer see the Repair winget message but cannot confirm effectiveness because of [BUG] Cannot Access Settings #3085. UPDATE 1: After resolving [BUG] #3085 I can confirm that WinGetUI is now running without errors. UPDATE 2: The WinGet malfunction error message has returned |
Please confirm these before moving forward
UniGetUI Version
3.1.4 beta 2
Windows version, edition, and architecture
Windows 10 22H2 19045.5198
Describe your issue
Since I installed UniGetUI 3.1.4 beta 1, I have been having problems with WinGet within UniGetUI and I am not offered any updates. Furthermore, I am constantly warned "WinGet malfunction detected", but repairing never works. UniGetUI says it has successfully repaired WinGet, but then I get the same warning.
If I click on "Repair WinGet", then a PowerShell window launches, but then while running I see the following (I had to grab a video of it to get a screenshot):
But despite that error while the cmdlet/script file is running, UnIGetUI always comes back and says that WinGet was repaired successfully as follows:
I have not changed anything. I have uninstalled UniGetUI and reinstalled it, but nothing changed. I have also tried enabling the "Use bundled WinGet" option, but that didn't help. The following are the settings I have been using for months other than temporarily trying the "Use bundled WinGet" option:
Please note that I can manually open PowerShell in an admin window and find and install updates via WinGet. I just don't know what to do to get WinGet past whatever problem it is having (or thinks it has) with WinGet. ???
I did update to 3.1.4 beta 2 today, but that didn't change anything. In fact, I tested again today and then produced the screenshots submitted in this submission.
Steps to reproduce the issue
All I have to do is launch UniGetUI and/or try manually looking for updates (since UniGetUI doesn't seem to be able to) and the warning about "WinGet malfunction detected" pops up. If I try repairing, then the whole loop starts.
UniGetUI Log
Package Managers Logs
Relevant information
No response
Screenshots and videos
No response
The text was updated successfully, but these errors were encountered: