[BUG] Winget eats 50% of my CPU when i close the notebook lid. #2049
Comments
|
you mean winget or wingetui? |
Sorry, winget = wingetui |
|
When you launch WingetUI, during the first 30s or so it will start loading all the packages and updates, so it is not fair to close the lid and expect it to consume no CPU. Please launch WingetUI, wait for all the packages to load and repeat the test. |
Sorry, English is not my first language and it's not easy to give feedback on a software whose background functions I basically know nothing about. It doesn't matter how long wingetui runs before i close the lid and it doesn't matter how long the lid is close - yesterday i watched some tv besides the laptop, over 90 mins, it run constantly. The taskmanager shows that wingetui exactly takes 50% CPU performance, all the time, when the computer is closed. I understand that wingetui isn't a paperweight of software, but that doesn't look like its working, that looks like its defective or bugged in software terms. Something triggers wingetui, when i close the lid and stops it, when i reopen it. Is there anyway to see what wingetui currently does? |
|
Please share your logs, both WingetUI and Package Manager Logs, both can be found on Wingetui -> More button -> logs |
|
Okay, i found something out, its not the lid itself, its the display powering off. I tried it on my desktop PC and can replicate the bug: https://www.youtube.com/watch?v=-QZCNloh7qw At 0:13 i'm switch off the monitor, the record stands still until i switch the monitor back on at 2:51. The resource manager says the wingetui process took 16,73% in the last 60s = 16,73 x 12 (6 Cores + HT) = 2,007 virtual Cores My laptop has 2 Core + HT and wingetui take 50% = 2 virtual Cores And for the logs, i posted them in the starter post. |
|
I can confirm that I am experiencing the exact same issue as described here. I am using WingetUI 3.0.2 and as soon as I turn off my screen, the CPU load goes up until I re-activate the screen. |
|
This issue should have been fixed by UniGetUI 3.1.0 beta 0. Please test this release out and let me know the results |
|
Unfortunately, it doesn't seem to be fixed in 3.1.0 beta 2. As soon as the screen is turned off, the load still goes up. |
|
UniGetUI constantly has 3-4% CPU load in the background. Is this the same problem or should I open another issue? |
|
Please check CPU usages with process explorer, and not with task manager. Task manager is sometimes unreliable for CPU usage data |
|
just sitting in the backgound, its in both tools always the top one and pretty constant
|
|
Will investigate. |
|
Maybe we are talking about different behaviors after all. Again, as soon as I turn off the screen, WingetUI / UnigetUI starts using up CPU like crazy. It stops only when the screen is turned back on, so it is impossible to catch it "in the act". I have recorded this behavior with Process Monitor while the screen was off (see attached screenshot).
I am now on 3.1.1 beta 1 running it as admin and the issue persists. The issue is extremely debilitating, as I am using WingetUI / UnigetUI on a living room SFF PC, which normally stays cool and is inaudible, but with this issue quickly heats up to dangerous levels and becomes unbearably loud. Like this, WingetUI / UnigetUI is unusable! |
|
Process Monitor allows to record traces which can help with debugging. |
|
Will take a look, thanks! |
|
Seeing the same issue I believe as well, with a twist. UniGetUI has been running for days in the tray on my laptop, was updating software yesterday even. Never closed the app, wasn't a fresh load of the app, just minimized to the tray. Went into the kitchen to make dinner, my desktop monitors went to sleep/locked my desktop, and when that happened my Remote Desktop session to my laptop presumably also blanked my laptop screen (though it remained open), and I came back into the living room to find my laptop fans running high/loud. Had no idea what it was when I logged back into my desktop and looked at my already open Remote Desktop to my laptop... I had open CoreTemp Graph Plugin and ClevoFanControl already because I'd been looking into issues where I suspected my laptop was overheating lately. They showed high CPU and temps while my screen was off, but didn't tell me WHAT it was.
Opened Process Explorer to the CPU graph and left it open, and went back to making dinner. Came back, and sure enough, it was doing it again... only this time on the ProcExp graph I could see it was UniGetUI. Same as the first time, as soon as I woke the screen back up, it stopped on it's own.
Maybe worth noting, I have the check for updates interval backed off to every 12 hours, so it should normally not be doing anything. A manual check for updates only takes a few seconds to complete, not the 10+ minutes of high cpu usage on the graphs. Can easily duplicate the situation above.
Initial startup spike in blue, high usage following locking the screen in yellow.
Logs don't contain anything useful, one error in the main logs for: |
|
I think this issue is related with this: microsoft/microsoft-ui-xaml#9703 |
Please confirm these before moving forward
Describe your issue
I'm using a Fujitsu LifeBook E5411 laptop with an Intel i3-1115G4 with Windows 10 Pro x64 (19045.4170).
I changed the Windows energy settings, so that the laptop doesn't go to sleep when i close the lid.
I don't know since when, but in the last days i heard the cpu fan a lot when the laptop was closed but after opening i did see anything suspicious, today i had time to search for the problem and i could finding using the taskmanager, its winget, it uses ~50% after i close the laptop lip and stops using it when i opening it again. I countercheck it, by closing winget - when nothing happens when i close the laptop.
Steps to reproduce the issue
Opening winget
Closing the lid
Wait some seconds until the CPU fan starts spinning
Opening the lid
WingetUI Log
Package Managers Logs
Relevant information
No response
Screenshots and videos
No response
The text was updated successfully, but these errors were encountered: