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...
Thanks, I also rolled back now to 126.96.36.19985 and can confirm the bug is gone in this version, too. I also experimented a bit with nvidia and e.g., disabling the drivers had no affect on the bug.
So for now I can state the following: something between 188.8.131.5285 and 184.108.40.20653 happened that creates a memory leak when using the fast startup (shutdown). On restart (fresh boot), this bug does not appear in 220.127.116.1153. @vitalyplatoff can you try whether the leak is gone on restart for you, too?
I also agree with you that this looks to be a bug, though I'm not sure - yet - if it is OS or graphics driver, obviously that would be up to Microsoft's or Intel's debug teams to figure out.
Before this report can reach Intel's debug team we definitely need to come up with a reproducible scenario... from personal experience I can tell you how frustrating it is when I get to see a bug report bouncing back to me because the debug team can't reproduce it on their systems.
I am trying to reproduce the issue as well on my NUC7i5BNK using Windows 10 version 2004 (build 19041.610) and drivers 18.104.22.16881 and 22.214.171.12453.
My test methodology so far is as follows:
As for fast-startup, here's my current configuration:
Please let me know if I am missing something or I should be doing something differently.
much thanks for trying to reproduce this bug. I observed the behaviour a bit more, and watching videos is not necessary. I recorded a vlc desktop video (length 3 minutes maybe), you see the dwm needing 211 MB. Alone with moving around the window I reach 300 MB ram after 1.5 Minutes aready (dwm is for graphical effects for windows, so moving around a window is enough to see whether this bug appears or not). You see the ram use accumulating.
Then you see me restarting the dwm process and the bug is gone (dwm goes maybe up a bit while moving the window but then it goes down again). The driver is 126.96.36.19953
Here's again what "fixes" this bug:
- roll back driver to 188.8.131.5285
- restart the comouter instead using fast startup through shut-down
- restart the dwm.exe in task-manager
Thanks for the video and your cooperation!
I tried doing the same (except I recorded the video using OBS) but moved the windows around for about 1.5 minutes and still can't see DWM utilization increasing nor doing it 20 minutes afterwards (it average at around 90MB).
The recording of this test is here.
I'm not giving up yet - far from it actually - I'll keep my computer ON overnight and use it as normal while keeping an eye for any memory leak. I'll report my results back tomorrow.
Just in case I still can't see the issue on my computer... let's start thinking outside the box:
For fairness sake, my NUC is using a clean OS installation (I installed the OS a couple of days ago) and I did install all available updates via Windows Update and the only apps I have installed are Steam, OBS Studio and the Unigine Heaven benchmark.
Much thanks for your caring. It's indeed strange that a percentage of users have this bug but I think the majoritiy doesn't have it (otherwise it would have been reported much earlier and more frequently). I updated windows to the preview version (also clean install, and the bug was still present). There might be other system ressources which might trigger this bug (like I suspected nvidia, but disabling that card doesn't make this bug disappear). I may try to play around with the task scheduler and disable some stuff there).
Regarding your questions (trying to translate):
active signal resolution 1920x1080
rate of actualization 60.020 Hz
color format: RGB
only the notebook display (hp pavilion 17-ab402ng)
I think you are referring to the ram slots used, I got this notebook with 1x8GB ram and upgraded the second slot with another 8 GB, so I have 2x8GB=16GB Ram
As I mentioned yesterday, I left my NUC on overnight and also did once in a while a Sleep and Hibernate cycles to see if there was any change in dwm.exe memory. It behave normally (never going above 150MB and coming down to less than 80MB afterwards).
I resized windows and moved around for hours to no avail. I also used the new input from @vitalyplatoff and launched Spotify, PowerPoint, Word and still no reproducible scenario. Just to explore a bit more I also tested by doing Win + Tab (several times) to launch the Desktop manager and this is the only instance I saw dwm.exe go above 200MB mark (only to go back to normal afterwards). See the recording I made here
I am also testing this issue on my Thinkpad T580 laptop but once again, it works fine on my side.
Can any of you test by doing a clean OS installation and verify if the issue occurs in that instance? It's a long shot, but I am suspecting an OS update might have introduced an update to dwm.exe that triggers the issue when paired with our new drivers... at least that might explain why not everyone sees the problem (perhaps they haven't received said update).
I made a clean installation back to 20H2 (didn't want to keep the preview version anyway).
Unfortunately, it did not solve it. The only way I have now is to roll back the driver to 184.108.40.20685 and hope you are able to find out what may cause this - in case you can somehow reproduce...
Just saying that on 220.127.116.1185 the bug is not present. @RonaldM_Intel , would it help for your debug team if I test all drivers from then:
to see with which update the bug first happened? Maybe you can find out in the update logs whether something was tinkered in the hibernate.sys or stuff like this?
Thanks for offering your help @Cody although I think driver wise we already know the most important data:
Issue appears on:
Issue does not appear on:
However, the current challenge is finding a reproducible scenario so I can report this to debug (with confidence they will be able to see the issue in their lab). In both systems I have tested this the bug is not appearing, which would suggest there is another variable that is triggering the bug.
Edit: I just thought of another variable that might explain why the issue is only appearing on some computers... and that would be the BIOS. Have any of you updated the BIOS on your computer recently? I know it would seem hard to explain why we appear to be moving away from the graphics driver as the sole culprit here (especially since older versions work fine) but there are instances in which it turns out the new driver is actually doing the right thing and the issue is introduced somewhere else (e.g. OS update, BIOS) with direct conflict with the new drivers .
I'll leave this discussion open for other users to chime in, but at the same time I would recommend you all report this to Microsoft so they can do the 1st level debug. Rest assured that if Microsoft confirms the bug is triggered due to an issue with Intel driver's code they will work with us directly to address it.
Ok, I'll stick then to 18.104.22.16885 until there is maybe a report one time that the bug is found. I already reported the problem to MS via the dev channel, but didn't get feedback (and now since I returned to 20H2, I likely never will).
Last Bios update was this:
Good day to all,
I'd like to add my voice into this issue as well. Since I've been having the same problem as Cody since day 1 of getting my new laptop. I had sourced high and low through various support forums and websites for a definite solution but to no avail nor any noticeable success.
I have attached the relevant SSU data and a screenshot for additional reference.
Taking cues from Andrew's questions as a base reference for streamlining the issue:
1- How often does the issue occur? Is it triggered when running any specific app or software?
The issue particularly applies every time when the system is booted up. There is no specific app or software that triggers this, through 2 to 3 hours of continuous use it will start to accumulate memory and bloat up to at least 2-3GB or even up to 10GB.
2- When the issue started, was there any recent change? (for instance: Windows® updates or graphics driver update?)
The above scenario occurred for both Windows 10 2004 and 20H2 (current), I have conducted a clean installation (deletion of driver software -> reboot -> re-installation of drivers). I've used every public release of the driver (i.e. builds 7985/8141/8190... ...8935) and it seems to be displaying the same issue.
3- Have you tested on a different system with Intel® Graphics? If yes, what are the CPU/Graphics model devices and the behavior?
I have another Intel-powered laptop. Running on an i7-7600U and HD 620 on Windows 20H2. The DWM runs well below 100MB and no memory leak.
4- [*Trimmed for relevance*] Do you have additional references regarding this statement? (so we can have more visibility of the behavior and impact of this).
This system is running on both Intel UHD 620 and Nvidia RTX 2080 Max-Q (version 457.09), as it's a gaming system. The RTX graphics has no issue as it's disabled under normal use conditions (i.e. web-browsing, YouTube, emails).
The system originally shipped with build 7642 as stock but I swiftly took the decision to do a clean upgrade on day 1, hence I'm unable to fully determine if the DWM issue persists.
Restarting the iGPU driver via the hotkeys doesn't resolve the issue, unless DWM process is killed and restarted, which briefly resolves this until few hours later...
I've also tested enabling/disabling hardware accelerated GPU scheduling, and it doesn't resolve the issue.
5- Please provide step-by-step instructions to replicate this behavior so we may try to test it.
I do not have any specific step-by-step instructions to replicate this problem, as it occurs randomly at time.
I hope these information would be valuable to the relevant teams analyzing and troubleshooting the issue.
I want to make a little input on the bug, cause i've been dealing with it from more than a month restarting dwm via processexplorer64, but i normally shutdown the pc with fast boot deactivated but the laptop takes a lot of time booting up (~10m or more). I deactivated hibernation too so i can check if that helps with the booting speed.
Also, i'll post here some pictures of how many memory dwm allocates on both ram and swap of different days i have saved on my laptop.
My laptop (Acer Aspire A515-51G) details:
For this bug i had to install Rainmeter+SysDash for monitoring ram/swap usage always before my pc get stuck. It started to happen after someone told me to use Intel Driver Assistant for recieving driver updates.
I am also experiencing this bug. My machine is Acer Helios 300 (i7-9750H) with Intel UHD 630 graphics and Geforce GTX 1660 secondary card and 32GB of RAM. However, the Geforce stays unused. The system version is 20H2 build 19042.630, definitely NOT a preview one. The bug started to occur quite recently, I cannot distinguish if it was related to updating Windows to 20H2 or related to updating the Intel drivers - their version is 22.214.171.12481. I do not install anything manually, all comes from Windows Update. The Windows installation is vanilla, not the one installed by the OEM. I did not update the BIOS, neither did I anything unusual. Some extra observations that may add something:
- My working set size of dwm.exe is between 2,0 - 2,5 GB
- I do not use hibernation
- The machine is rarely restarted, I use sleep very often
- This week it was restarted on Saturday and the memory leak occured on Tuesday. Before Tuesday it was ca 150MB.
- It might have something to do with sleep. I am monitoring the working set size with Performance Monitor and found out, that the memory increased some time after the wake up, but didn't catch the exact moment. On the other hand, by then it had already completed a few other sleep-wakeup cycles (Sunday, Monday) before, and it was fine.
- I use the screen saver. That's unusual, but not sure if there is a relationship. It is standard Windows Text3D screensaver.
- Some time before I observed the 2GB usage, I launched modern UWP remote desktop client application. Not sure if there is any relationship. Maybe something after launching UWP apps.
- I use classic mstsc RDP client very often, probably this is not relevant.
I've noticed that majority of the posters in this thread have Nvidia GPUs. I was wondering could it be something to do with the GPU switching or some kind of parallel rendering that's leading to the massive leak?
Unless if the Intel driver is not integrating well with the Nvidia Optimus setting, just some wild intuition running in my mind... Based on what I've read online, it seems that the Intel driver is in full charge of the switching depending on GPU demand per application.
This was also my suspicion earlier, but disabling nvidia drivers didn't make it better. However there might be other nvidia software running too that cannot be disabled, interfering with Intel GPU and thus cause this bug.
Maybe intel lab has a computer with a double gpu (intel+nvidia) to test?