dwm.exe (Desktop-Window Manager) uses high memory with Intel Intel HD Graphics 630. This problem has been reported before:
Here's a screenshot of my dwm ram usage after 2 hours (1.6 GB):
Please, this bug is already known for 3-4 months, and I do not want to reinstall a 2019 driver...
Now at 627mb ram use and counting...
Got to be security implications as well with this memory leak...
If i look at the strings within each address I see loads and loads of them with just the string "cqTY"
Thank you for all your input. I am still trying to replicate the issue and used the same hardware as before and this time setting up a VM with VirtualBox and running Ubuntu while making sure hardware acceleration is enabled in the VM... bad news is that I'm still unable to see the issue.
Can you upload your SSU files? this information should help us identify what could be triggering the issue on some systems but not on all.
You could try creating a few photo slideshow with music with the Microsoft Photos application, that caused my DWM to "inflate" into a massive memory leak.
I've also re-attached my SSU files for your convenience.
I got it! After couple of days of running Performance Monitor (standard Windows tool) focused on dwm.exe process, now I know what causes the rise of the memory consumption.
In my case, it is running Oracle Virtual Box 6.1.16 (the newest, but internal VBox additions are 6.1.12) with linux virtual machine (kernel 4.15, LinuxLite distribution), VMSVGA graphics adapter and 3D acceleration enabled.
After the reboot, the usage was 150MB and it was stable for 2 days. Today I ran VirtualBox and it immediately increased to ca 400MB. I ran it again and now it is 600MB. It is NOT released upon closing VirtualBox. This behavior seems to be reproducible. Ran for the 3rd time, and now it is 730MB.
I know, it looks like Oracle is to blame in my case, because it is not very probable that other affected users also run VirtualBox. However, I suppose it may have something to do with applications that use 3D hardware acceleration.
Getting the same bug, HD630 plus nvidia 1050ti on laptop.
DWM.exe gets to 3-4gb
Could someone use this to find the leak and tell intel:
Really annoying as it eats into ram use.
need a fix soon please.
Looking through you logs, I see constantly:
are the CRT leaks?
I've had this issue as well. In the process of downgrading my driver since nothing else has worked. I also want to note that the new XBox App and Steam seem to slam DMW and cause its memory usage to increase a lot. I don't think they're at all related to the bug but using the Xbox gamepass app and then closing it out to see if DMW clears may be a more reliable test to see if there's a leak.
Hi to everyone.
I saw this problem about 3 months ago an reported it via Feedback-Hub (https://aka.ms/AA9ibru) & Twitter (https://twitter.com/MrX_1980/status/1299693776622047233) to Microsoft.
Sadly I still have no repro, but I'm still searching for a good repro for you.
I noticed it for example after a longer usage of many Youtube clips (switching many times between full screen and normal screen, likes and adding clips to my playlists) with Microsoft Edge Stable (Chromium) and using other programs like WhatsApp Desktop, Twitter Desktop App, ... . I also use sometimes standby/hibernate.
My temporary fix is to do a full Windows reboot (WIN + x -> Shut down or sign out-> Restart)
Lenovo Yoga 710-14IKB Type 80V4 / BIOS Version 2XCN38WW(V2.12 / 2018)
DualCore Intel Core i5-7200U, Intel HD Graphics 620 (no other GPU)
LG Philips LP140WF7-SPB1 [14" LCD] (only Notebook display) / 1920 x 1080 at 60Hz
1x 8GB DDR4 RAM at 1066/2133 MHz (SK hynix HMA81GS6AFR8N-UH) / 15-15-15-35 (CL-RCD-RP-RAS)
Currently I use:
Microsoft Windows 10 Home x64 Dev-Channel (build .21277.1000)
Intel graphics driver 188.8.131.5216 via Windows Update (With older drivers & Win10 dev builds that was released the last ~3 months too. I will try other drivers later this week.)
No progress has been made since we haven't been able to find a way to reproduce this issue in our lab using different platforms (laptops, NUCs with and without Hybrid graphics) and all the input you have provided so far.
I would recommend reporting this issue to Microsoft. Usually if they find a fault in the OS component (dwm.exe) linked with the Intel driver then they will work directly with Intel to address it.
I have this issue too on my NUC8i7bek (Iris Plus 655 graphics) with fully up-to-date Windows 10 and currently the latest beta driver 184.108.40.20677, though every driver version I have tried has been affected. My system also has a 4K monitor (Dell U2720q, specifically). The hardware is important here, because I cannot reproduce the issue on a NUC6i5syk (Iris 540) with a 1080p TV and the same driver and OS version.
I do have a method of reproducing this issue 100% of the time. My system, for the record, has fast startup and hibernation both disabled, and I never use sleep. It is configured to turn the monitor off (and lock the screen) after 5 minutes of inactivity. If I press Win+L to lock the screen manually, the monitor shuts off within a minute or so.
To reproduce the issue, I reboot my system and log in. Then I lock the screen and wait for it to shut off the monitor automatically. Once it does, I press a key to turn the screen back on, log in again, and repeat the process. The second time the monitor comes back on, if I perform almost any action, DWM starts leaking memory very rapidly. This includes opening/closing windows, moving windows, scrolling within windows (browsers, both Firefox and Chrome, seem to make it leak the fastest), and watching videos within a browser all cause leakage. Then, if I lock the screen again, wait for it to shut off, and wake it up a third time, it stops leaking RAM (though what was previously leaked is not freed). The leakage will occur again after some number of additional monitor sleep cycles, but whenever it is leaking, a sleep cycle will temporarily stop the leak.
I have also found that if I use SysInternals RAMMap to "Empty Working Sets" followed by "Empty Modified Page List", the leaked RAM is freed. This does not stop the leaking, however, if it was actively occurring.