Open garrettsummerfi3ld opened 1 year ago
For anyone looking wanting to disable Dev Home from running in the background (due to memory leak or otherwise):
Settings
Apps
> Installed Apps
System Components
*...
next to Dev Home
and select Advanced options
Background component permissions
change Let this system component run in background
to Never
Terminate
click Terminate
Even if the UI is closed it can consume resources.
@garrettsummerfi3ld / @krschau / @mathewleeza I'm truly furious about this right now. I never even installed this thing and apparently it can't be uninstalled. How has a memory leak discovered 8 months ago still not been fixed for a System Component
tool that has 75% one star ratings in the Windows Store.
Please kindly revisit the reviews. They are very damning and what could be a great tool now has a very tarnished reputation.
My previous comment doesn't seem to be a complete solution - apparently it just resurrects itself.
I think the below notification window is acting like a 'Widget'. It clearly is a widget - but not a user widget. Having realized this I dismissed it and at least the CPU seems to be back to zero.
... I'm truly furious about this right now. I never even installed this thing and apparently it can't be uninstalled. How has a memory leak discovered 8 months ago still not been fixed for a
System Component
tool that has 75% one star ratings in the Windows Store.
@simeyla I am literally the person who made the issue, I have no affiliation with Microsoft or any of their subsidiaries. I just use Dev Home and had an issue a while ago.
If you super want to remove this, you can uninstall it with PowerShell. Run with admin privileges and you're set. Removes all users Dev Home instance on a Windows machine.
Get-AppxPackage -AllUsers -PackageTypeFilter Bundle -Name “*Windows.DevHome*” | Remove-AppxPackage -AllUsers
As for the performance issues. I haven't had memory leak issues recently but I haven't looked too closely for those issues.
I have a different system and haven't noticed memory issues, however shutting down and starting it back up does help it go away, so periodic reboots do help with the issue. I perform regular reboots now compared to that machine as it performed nightly tasks and couldn't be shut down during those tasks.
Seems useless, but I don't know when it sucks back up so much resources as I don't watch my Task Manager like a hawk.
Only possible explanation is similar to #1398 and with the "Extensions" tab having the closable window blurb, although its not consistent with performance hits as sometimes it does use substantial resources and sometimes it doesn't.
Current setup is:
Dev Home Version: 0.1201.442.0
OS Build Version: 10.0.22631.3374.amd64fre.ni_release.220506-1250 .NET Version: .NET 8.0.1
Extensions: Microsoft.Windows.DevHomeGitHubExtension_0.1200.442.0_x648wekyb3d8bbwe Microsoft.Windows.DevHome_0.1201.442.0_x648wekyb3d8bbwe Microsoft.Windows.DevHome_0.1201.442.0_x648wekyb3d8bbwe 9932MartCliment.WingetUIWidgets_0.4.0.0_x64g91dtg5srk15g
Widget Service: MicrosoftWindows.Client.WebExperience_424.1301.450.0_x64__cw5n1h2txyewy
CPU: AMD Ryzen 9 5950X GPU: NVIDIA GeForce RTX 3090 RAM: 64GB OS: Windows 11 Pro 23H2 (22631.3374)
All of which is installed through the Microsoft Store, not built from source if that helps any for debugging.
@garrettsummerfi3ld So you should be furious too! :-)
First, apologies for directing this at you and I appreciate your detailed response and notes.
I don't know why it's not been addressed yet - it's nearly been a year. This issue is probably affecting anybody that's ever opened it. Hopefully someone from Microsoft will respond to this. Here's my conclusions from today. I'm ok having it installed as long as it's using 0% (which mine now is).
I recently got a new laptop and it was getting very hot idling. Dev Home was pushing it over the edge, so that's why I was extra mad.
I only knew Dev Home
even existed because I'm using the new Dev Drive
feature and found Dev Home
in passing.
Just now I went back to my old PC and managed to duplicate the problem exactly in the same way.
When opening for the first time it downloads a new version. That's the version with issues. No issue until you open it.
Dev Home
seems to be installed for all Windows PCs, but again this shouldn't cause an issue unless people open it.
Once opened it starts continuously using CPU even after being closed. As much as 15% on my older laptop.
I had to close ALL widgets and all 'dialogs' under all 3 tabs AND I had to terminate it too to get CPU down to 0%.
I read from the reviews in the Microsoft Store that the uninstall command you provided may not be permanent. It's also a tool I may be interested in having around if it actually works. I'll try that if it reincarnates.
And probably the biggest reason I was mad - I opened a new issue which was closed as a duplicate of this one which hasn't even been addressed. 🤷♂️
I expect https://github.com/microsoft/devhome/pull/2483 will make a difference here, you'll see that change in the next release. Also @dkbennett, let's not forget to include your "check if Dev Home is running" change in the CoreWidgetProvider, too.
Just left running for a weekend. 😢
I profiled the CPU and GPU widgets and nearly all the CPU resource consumption (99%) is coming from PerformanceCounter.NextValue(). The problem with this method is not unique to Dev Home. Not sure if the memory leak is also originating there, but I will investigate.
There are a large number of performance counters being used and the constant calls to NextValue() is the source of the CPU consumption. This is exacerbated because the widgets keep running even when Dev Home is not running since they are part of the Widget platform and not unique to Dev Home, and these widgets are created and pinned by default.
There are several things that can be done here, still investigating the best options.
I profiled the CPU and GPU widgets and nearly all the CPU resource consumption (99%) is coming from PerformanceCounter.NextValue(). The problem with this method is not unique to Dev Home. Not sure if the memory leak is also originating there, but I will investigate.
There are a large number of performance counters being used and the constant calls to NextValue() is the source of the CPU consumption. This is exacerbated because the widgets keep running even when Dev Home is not running since they are part of the Widget platform and not unique to Dev Home, and these widgets are created and pinned by default.
There are several things that can be done here, still investigating the best options.
resmon
does it while having almost non-noticable CPU usage.
Just left running for a weekend. 😢
Do you know which widgets you had running during this time? Specifically which of these: CPU/GPU/Memory/Network/SSH keychain.
I was able to replicate the memory growth and it looks like the performance counter is where it is originating. Running many perf counters slowly grows over time. Not using perf counters did not observe any memory growth.
Dev Home version
0.301.198.0
Windows build number
10.0.22621.1992
Other software
OS Build Version: 10.0.22621.1992.amd64fre.ni_release.220506-1250 .NET Version: .NET 6.0.18 Windows 11 Widgets Version 423.13900.0.0
Steps to reproduce the bug
In the Windows 11 Widgets menu, pin the following from Dev Home:
There doesn't seem to be a particular order that you need to have the widgets in for this to reproduce.
Wait. This was noticed with uptime on my machine being 3 days.
You do not need to launch Dev Home for the memory to leak, just the widgets need to be enabled.
Expected result
Memory does not increase substantially and can run in the background without clawing resources.
Actual result
Memory usage is ~11GB alone, with the CPU usage taking up ~6-10% in the background.
Included System Information
CPU: Intel Core i9-12900K GPU: NVIDIA GeForce RTX 3090 RAM: 128GB OS: Windows 11 Pro 22H2
Physical Memory: 127.73GB (89.41GB free) Processor Architecture: x64
Included Extensions Information
Extensions: Microsoft.Windows.DevHome_0.301.198.0_x648wekyb3d8bbwe Microsoft.Windows.DevHomeGitHubExtension_0.300.198.0_x648wekyb3d8bbwe