marticliment
commented
6 months ago Please try WingetUI Beta.
Does this issue still happen?
Closed snaphat closed 6 months ago
marticliment
commented
6 months ago Please try WingetUI Beta.
Does this issue still happen?
snaphat
commented
6 months ago The issue still occurs with the beta.
I found out a better way to trigger the issue on my end. Simply installing and running WinGetUI causes the issue to crop up, until deinstall. I can exit the WinGetUI.exe process and the issue stays until deinstall. Not sure what that implies or means. Dunno if you all are doing a DLL hook or something similar.
I took a video of the issue occurring with OBS showing the following: 1) Task manager running (bottom right) WinGetUI 3.0-beta0 not installed. 2) Installing WinGetUI and running it. Subsequently, Task Manager freezes. 3) Exiting WinGetUI from the system tray. Task Manager is still frozen. 4) Deinstalling Task Manager. Subsequently, Task Manager unfreezes.
https://github.com/marticliment/WingetUI/assets/5836001/6302ecb1-bec1-45db-9b05-36c43992153d
marticliment
commented
6 months ago Dunno if you all are doing a DLL hook or something similar.
Nope
- Task manager running (bottom right) WinGetUI 3.0-beta0 not installed.
- Installing WinGetUI and running it. Subsequently, Task Manager freezes.
- Exiting WinGetUI from the system tray. Task Manager is still frozen.
- Deinstalling Task Manager. Subsequently, Task Manager unfreezes.
Killing the task manager and running it again with WingetUI installer what does?
snaphat
commented
6 months ago Killing the task manager and running it again with WingetUI installer what does?
The task manager freezes just the same as shown in the video even when you start the task manager later (after the install)
snaphat
commented
6 months ago The issue is due to #1799. Essentially, what has happened is that WingetUI has an absurd number of entries showing up in the task manager under startup apps (see the image below for the count) and it's causing lag and hanging it.
Some notes:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run]
"WingetUI"="\"C:\\Program Files\\WingetUI\\WingetUI.exe\" --daemon"From this I surmise that Windows is storing all of the entries somewhere on permanent basis and referencing them as long as a key with the value "\"C:\Program Files\WingetUI\WingetUI.exe\" --daemon" exists. It's probably hashing the value and doing a lookup. (Note, the key name doesn't matter) (EDIT: It appears to use UUIDs)
So, the question is where the entries are being stored, and the second question is why WingetUI is producing multiple entries in the first place. In #1799, you seem to indicate it has to do with multiple subprocesses being forked, and that the entries should be transient, but the latter doesn't appear to be the case, given that they persist between reboots.
snaphat
commented
6 months ago Purging C:\Windows\System32\WDI\LogFiles removes the duplicate entries. This appears to be where the information is stored for startup performance data.
marticliment
commented
6 months ago The reason for so many process being launched is because every spawned process from WingetUI, even with the same executable but different arguments gets loaded onto Task Manager's cache, therefore bloating the entry. The real issue is that there is no way to avoid processes from being registered by taskmgr
This is therefore unfixable from WingetUI, so the best I can say is to post the issue on Feedback Hub.
snaphat
commented
6 months ago I haven't seen other startup apps exhibit this issue. I believe it's probably because they either don't start subprocesses or use another mechanism (such as operating as a service) so that they don't have performance data recorded or shown in the startup list.
What's happening in this case is that all of the performance data for the entire hierarchy of subprocesses is being recorded to the point that upwards of over 3 thousand entries can appear in some cases. I checked the list and its' a lot of git, conhost, clink, choco, cmd, powershell, and busybox processes. Once that occurs, task manager is out of commission permanently since the entries do not remove upon reboot. Given this, I'm surprised you wouldn't be looking to re-architect the startup process to work around the issue in some way (e.g. using services).
While it may not be WingetUI's fault per-say, we both know that submitting the issue to the feedback hub is not going to result in a forthcoming or timely fix (ETA would likely be years at best). Moreover, the behavior of showing subprocesses is by design and technically correct on MS's part and in most cases a reasonable behavior. It's only unreasonable for startup apps with unbounded forking, as is the case with WingetUI.
It's a whole other question as to why the task manager performs so slowly with 3k startup entries and hangs. It definitely shouldn't, but the task manager has been pretty bloated and slow since it got upgraded. Unfortunately, MS isn't going to fix that in a timely manner either it seems. I suspect, the task manager computes the "startup impact" on the fly and that's why it's so slow.
You are kind of caught between a rock and a hard place here. It's not WinGetUI's fault, but I'd still be looking for a workaround if I were you because it does cause real world issues for users.
marticliment
commented
6 months ago Given this, I'm surprised you wouldn't be looking to re-architect the startup process to work around the issue in some way (e.g. using services).
If I need to rearchitect the startup process I will, but I'd like to wait a little bit before, since I also am on Beta Channel and I have never experienced those issues, and I don't have a top-end pc. Furthermore, from all the userbase I have seen only two people reporting it, so maybe this is a bug with a new feature that has been set to gradually roll out, or maybe they will fix it. This is why I suggested to post feedback on Feedback hub.
Furthermore, while Windows Insider beta builds tend to be quite stable and usable, they may have broken code. This is why they are beta and not production. By being on the beta channel you must understand that those things can happen. Therefore, I'd insist on reporting the bug, and mark it with the "Breaks Usability" tag. They will for sure look into it.
Please confirm these before moving forward
Describe your issue
If
WingetUI 2.2.0is specified to run on login viaComputer\HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run(C:\Program Files\WingetUI\WingetUI.exe --daemon) then taskmgr.exe will no longer behave properly inWindows 11 23h2when started. Specifically, it will run slow in general on many of the task manager tabs and hang when selecting theStartup Appstab or resizing the window itself. This issue occurs even if WingetUI is not running -- until logging out of the windows account. If WinGetUI is manually started after login, the issue doesn't appear to occur (reliably or at all?) So it seems like some race condition.This was occurring in insider builds of windows as well for the last year or so, but at the time I assumed it was just a random windows issue. Finally traced it to WinGetUI today.
Steps to reproduce the issue
No response
WingetUI Log
Package Managers Logs
Relevant information
No response
Screenshots and videos
No response