winget-cli: Windows Package Manager Server runs on high CPU
Brief description of your issue
I’m not sure if this is the right place to report this, but the “WinGET COM Server” with a child process of “WindowsPackageManagerServer.exe” is using up a lot of CPU on my system. When killed, it just respawns immediately.
I’m not the only one with this issue: https://www.reddit.com/r/techsupport/comments/162dj42/what_is_winget_com_server/
Steps to reproduce
Not sure how to reproduce.
Expected behavior
It shouldn’t run on high CPU for extended periods of time.
Actual behavior
It runs on super high CPU all the time.
Environment
Microsoft.DesktopAppInstaller_1.20.2201.0_x64__8wekyb3d8bbwe
WindowsPackageManagerServer.exe version 1.20.2308.8001-v1.20WPMv1.5
Hope that helps...
About this issue
- Original URL
- State: open
- Created 9 months ago
- Reactions: 33
- Comments: 70 (7 by maintainers)
We believe we’ve identified the source of the high CPU events. We’re looking to make changes in WinGet to lower the impact as well as working with partner teams to help make their calls and calling pattern more efficient.
Same issue here. Started pretty much right after booting up, on a machine that I haven’t used since last Friday.
Process has accumulated about 10min of CPU time (100% usage on a single core) and as I am writing this, it has now finally stopped.
I know this is like talking to a wall, but the amount of “random” background processes with zero UI indication of what is happening has really gotten out of hand in recent years. The more stuff constantly running on the background, the bigger the potential of things going wrong or eating up CPU time for no apparent reason.
Yes, user experience (in terms application performance) is not affected too much since most code still runs single-threaded and modern computers are routinely equipped with more than half a dozen cores. But especially on mobile/laptop devices, this causes a large nuisance due to high noise (for no visible reason), causing distraction and reduced battery life.
Hey all, we’ve almost completed our internal testing.
We will publish the update here at GitHub (for people actively seeking the update) and to Windows Insider Beta and Windows Insider Release Preview. After a few days of feedback, this will be pushed out to everyone.
Thank you for the link to the note on Performance Improvements related to caching. However, the note does not explain all of the network communications to akami that are associated with the package manager issue. I looked again last night in Resource Explorer while this issue was taking place, and while low in bandwidth, there was continual transmission to/from the microsoft akami servers.
Windows already knows what updates have been downloaded and what updates are needed – all updates have are completed before this package manager behavior kicks in. So what is this stream of network traffic with akami that your caching is indented to benefit?
Adding that information to the 296a53d link would be very helpful.
I appreciate the optimization effort, and the initial results look promising. However, based on the observed behavior, even with a 99.9% load reduction, it will still be an unacceptable load. I suspect there may still be an underlying bug contributing to this. Is there any connection between the Visual Studio update and the issue we’re observing, or is it just a coincidence?
Hey all. We’ve identified an area where we can reduce the CPU utilization for this calling pattern. We’re working on an update, and we’ll publish it as soon as it’s ready.
Update: We’re performing some testing now to see if we can at least get some anecdotal measurements for the improvement.
How to remove the modern App WinGET: open PowerShell as admin and enter the following command: “get-appxpackage Microsoft.DesktopAppInstaller | remove-appxpackage”
PS: i don’t know why but the editor removed 2 asterisks from the command above, one before Microsoft and one after AppInstaller. You must insert them.
Ok, you have an ETA on a fix for this? And please, not one that “lowers the impact”, but one that fixes the issue.
Like @raphaelcardoso I’m sceptical. For me, the process hung for at least 30 minutes before I managed to finally kill it by uninstalling some things. Endless loop * 1/6 is still an endless loop.
No, I want fix, not a hack
I have taken ownership of the file, disabled inheritance of permissions, and left the permissions like this:
Permissions on my user are Read and Write, but not Read & Execute:
Now the exe is no longer able to launch or restart itself, and I’m not getting spammed with errors anymore.
Windows 10 Pro. Windows Package Manager uses one logical CPU (I have 2 cores, 4 logical CPUs and it uses 25% of the total CPU). It does not use any Disk I/O and almost no network. I always log in with non-admin user.
Restarting Windows and logging in with Administrator account solves the problem. Some process (Wsappx …) runs for less than a minute with a high CPU usage and then CPU usage returns to normal.
After restarting with normal user “Please wait” appears (some update are being installed?) and runs fine until the next Windows update.
While there’s no patch/solution, another option is simply “suspend” the process using windows resource monitor, instead of killing it.
Possible permanent workaround:
After renaming the folder
%LocalAppData%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe
with suffix “_bak” the commandwinget update
rebuild the whole folder and so far no more high cpu usage is occuring. So far there are no side effects doing that, winget and Windows Store working normally as usual. Suspending the process did not help for me because eventually a new process spawned anyway in my case.It seems there may be a problem with the various database files inside that folder. Looked into them with “DB Browser for SQLite” and there were entries with already removed programs. Maybe the process was stuck in an never-ending loop because of these “corrupt” databases. But still weird that this issue may be so widespread. It could be the case that much earlier versions of winget handled the databases differently.
It is the same with me… when I end the process it is restarted immediately.
Environment
https://github.com/microsoft/winget-cli/commit/296a53dbedffabfd14b60f43e1a7abae0200cb75
[OFF-TOPIC]
Shifting the focus here, in situations like this where it’s causing a single logical processor to run at 100% capacity (25% of my CPU), there should be a fast, automated rollback process.
It might be achievable using components already implemented in advanced technologies like Click-to-Run, containers, MDM, or the Microsoft Store.
In an emergency, authors of Microsoft Store apps should be able to revert to a previous version almost instantaneously, triggering a deployment as lightweight as sending low-priority push notifications and symlink swapping.
Hey all, we’ve identified a couple of areas where we’re able to make substantial improvements in the client. Our initial testing is showing a solid reduction in the time it takes for these processes to complete. It amounts to 5/6 of the time. Something on the order of ~1000 ms per iteration to ~130 ms per iteration on the hardware we’re testing on. I’m expecting we will push this update out early next week if the remaining testing all passes.
Agreed. Effectively deleting the file on individual machines for those users just smart enough to know how to take ownership of a system file and renaming it is not a solution. It leaves every other windows user stuck with the problem. Good lord. Think of the 99.9+% of the installed base that has no clue about hacking file permissions. Think of your grandmother or grandfather or child puzzled, concerned their computer is broken because it is busy for hours on end.
Interesting.
Thanks for sharing.
Like @bdgit I also updated Visual Studio 2022 from v17.7.4 to v17.7.5 yesterday and I’m now also encountering this problem. MICROSOFT, WHERE ARE YOU? PLEASE SOLVE THIS CLEAR PROBLEM.
I used @rerigam’s advise and uninstalled this rogue application by using:
get-appxpackage *Microsoft.DesktopAppInstaller* | remove-appxpackage
Note: I did have to kill the task repeatedly in task manager and completely restart Windows to actually make it stick.
They disappear because these text editor accept markdown. So the asterix is interpreted as making the text between them bold. To avoid this, just put code statement into backticks.
So a statement like this
something.Method()
can be achieved by typing in`something.Method()`
.same porcodio
hello all
i just noticed this program today, also taking much cpu, after i removed some office updates from yesterday, it went away; will keep an eye on task manager, but since removing the updates and a reboot and while creating the account here and typing, the program didnt came back so far.
Had this same issue. You’ve got a pretty outdated version, update “App Installer” via the Microsoft Store or WinGet as described here and the problem should go away.
Same here. WindowsPackageManagerServer.exe is using 25% of the CPU and can’t be killed. Microsoft.DesktopAppInstaller_1.21.2701.0
Same here. The process keeps running after I close its parent (a
pwsh.exe
instance). I can’t copy the log from%LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
'cos it’s locked.