Windows 10 V1903: RDP (dwm.exe) causes high CPU load, freezes VMs

[German]Windows 10 May 2019 Update (version 1903) has a bug in Remote Desktop Connections (RDP). These cause a high CPU load on a CPU core when disconnecting the session. There are also reports that VMs freeze on RDP connections (when not enough cores are allocated). However, there is a workaround.


Advertising

It is a bug whose solution has already been mentioned here in the blog in another context. But I decided to prepare the topic separately again. Maybe it will help those affected.

Windows 10 V1903: Issues with RDP connections

If you establish a remote desktop connection (RDP) to a computer with Windows 10 May 2019 Update (Version 1903), you should be careful. If you disconnect the session without logging out, the process dwm.exe (Desktop Windows Manager) hangs on the client. The process will then fully utilize a CPU core.

DWM.exe, hohe CPU-Last
(Click to zoom, Source: MS-Answers-Forum)

This high CPU load remains until the next login. Users opened this thread in the Microsoft Answers forum on June 15, 2019 with a description of the bug and posted the screenshot above.

After exiting a remote desktop session, cpu load goes up (dwm.exe) until next login

When I access another Windows 10 PC via remote desktop and then exit the remote desktop session, the CPU load goes up. It is DWM.EXE that causes it.

The user has taken the usual measures to exclude his system as a cause. He wrote what he’ve checked:


Advertising

What I did to exclude other causes:

– scanned for viruses (yes, DWM.EXE is the original one from MS)
– made sure no magnifier was active (Google proposed this)
– made sure no screen saver is active and nothing else is on my lock screen
– made sure the gfx driver (Intel integrated) is up to date

He also performed system file checks with sfc /scannow and dism without success. The whole thing is simply a bug in Windows 10 version 1903. The thread has already received over 10,000 user votes that have the same problem. In addition, a user has linked a number of other sources in the thread. So far, however, Microsoft has not provided a fix or even left out the problem at all.

Workaround: Force XDDM driver use

In mid-July 2019, I published the blog post Windows 10 V1903: Remote Desktop shows Black Screen, which deals with a different problem in RDP sessions (black screen). My suggestion for a workaround there was to force the use of the XDDM driver instead of the normally used WDDM graphics driver.

  1. Launch gpedit.msc with administrative privleges.
  2. Then navigate to the following branch in the Group Policy Editor.


(Click to zoom)

Use the branch: Computer Configuration->Policies->Windows Settings->Administrative Templates->Windows Components->Remote Desktop Services->Remote Desktop Session Host->Remote Session Environment, set the Policy Use WDDM graphics display driver for Remote Desktop Connections to Disabled.

Once this policy has been disabled and the commit may have been forced with gpudate /force, the problem should be fixed.

Already in the German user comments there was a reference to the MS forum post linked above – and this comment and another comment describe that the workaround helps with a freezing VM. In the MS forum post, user Dr4g0n 36 writes that for him forcing the XDDM driver also helped. I myself, in addition to the comments here in the blog, have become aware of the problem again through this entry at German site administrator.de.


Advertising
This entry was posted in issue, Windows and tagged , , . Bookmark the permalink.

19 Responses to Windows 10 V1903: RDP (dwm.exe) causes high CPU load, freezes VMs

  1. Biggy says:

    Awesome article!!!
    I wasn’t the only one.

    Today Microsoft fixed it.

    KB4512941

  2. Azarias says:

    I was having the same problem after installing update 1903 on my windows 10 running on virtual machine. Well the Microsoft update KB4512941 didn’t fix the problem[fixed other problems(ESENT – Event ID: 455 error, coming up continuously noticed on task viewer) but not the one with cpu going up after exiting a remote desktop session]. Although the suggested solution, to force the use of the XDDM driver instead of the normally used WDDM graphics driver via gpedit, worked like a charm. Thanks a lot for your article very useful. Bravo guenni. Many many many thnx!!!!

  3. Chris says:

    Thank you very much for this solution, I was also in this case on a virtual machine and I confirm that the KB4512941 did not solve this problem.

  4. Advertising

  5. Peryll says:

    Thank you for the article. Saved me a lot of work.

  6. Silviu says:

    Thank you !!!

  7. mike says:

    Thank you, tried so many things that didn’t work. This fixed it.

  8. Ichiro says:

    Thank you!! I was so lucky to find this article today.

  9. mentif says:

    Thank you, It work fine.

  10. mario witdoek says:

    Hi Mr Born,

    The CPU of my VM went from 8% down to 1%. Vielen Danke!

    Mario

    PS: you must be family of Jason Born, another miracle man :p

  11. Drummerboy says:

    Many thanks!!! Costs me many hours before I found this fix.

  12. Bill says:

    After spending hours on this, including rebuilding VM from scratch, this little workaround seems to have solved the problem.
    Vielen dank! And happy Reunification Day!

  13. Andrew says:

    God bless you sir. I was tearing my hair out.

  14. eric says:

    Thanks for this!
    Just solved a huge issue for me.

  15. Alessandro says:

    Thanks!
    No windows upgrade did the job! (I upgraded till last version available)
    This solution solved the problem

  16. CymonZ says:

    Thank you very, very much !!

    I’ve been plagued for two weeks with this issue…ever since my Win10 VM’s updated to “the latest and un-tested” 1903 that I’ve been using on my desktop for a while and thought OK to use. C’ept I had to reboot them every morning.

    Yes: DWM was the culprit, but I only found out after lots of what-if’s.

    Your WDDM solution disabled the problem.

  17. rell says:

    THANK YOU!!!!!!!!!!!! THANK YOU!!!!!!!!!THANK YOU!!!!!!!!!!!! THANK YOU!!!!!!!!!THANK YOU!!!!!!!!!!!! THANK YOU!!!!!!!!!THANK YOU!!!!!!!!!!!! THANK YOU!!!!!!!!!THANK YOU!!!!!!!!!!!! THANK YOU!!!!!!!!!THANK YOU!!!!!!!!!!!! THANK YOU!!!!!!!!!

Leave a Reply

Your email address will not be published. Required fields are marked *