DWM.EXE High CPU (One Core) On Target System after Remote Desktop Disconnect on Windows 10 x64 1903 (Fully Patched)

*** PROBLEM RESOLVED BY KB4522355 RELEASED OCTOBER 24TH 2019. ***

Two systems,

  • Intel NUC with Iris Plus Graphics 655 running latest drivers 26.20.100.6890 
  • the other with Intel HD Graphics 2500 running latest drivers 5.33.48.5069 

On completion of a remote desktop session, the target system shows high CPU utilisation (one core running at 100%) for DWM.EXE - the newer machine (Intel Iris Plus 655) will eventually crash several hours later - I suspect a memory leak such as the previous one affecting QuickSync.

If I change the drivers to "Microsoft Basic Display Adapter" then things return to normal re: DWM.EXE. It's not a long term fix as one of the machines is my Media Centre PC and I lose audio output on it, the other is a headless Plex server and I lose "Quick Sync" hardware transcoding.

Anyone else seeing this ?  If so after a bit of digging I've identified a short term workaround.

I believe there is a problem with the Microsoft RDP code in 1903 (an area which seems to have had a major internal overhaul), and I document a successful workaround. 

For clarity,

  • the behavior started with 1903
  • one system is an Intel NUC NUC8I7BEH PC with 16Gb Corsair Vengeance Memory and an Intel 760p 256Gb SSD; the other is a Chillblast Fusion Vacuum PC based on a P8H77-M motherboard. However other machines with nVidia GPU's are also affected, so this is NOT an Intel problem.
  • my testing consists of using a third machine running Windows 10 x64 1903 (fully patched) to run the Remote Desktop client software. The "targets" I refer to are the two machines I mention acting as RDP Host machines. Both demonstrate the high CPU DWM.EXE after taking them over and then disconnecting (the NUC has an 8 core CPU so shows 12.5% CPU) and the other machine based on an Intel P8H77-M motherboard.

It seems Microsoft has done significant engineering to Remote Desktop in Windows 10 1903 and I now believe a significant bug exists in the Microsoft code.

In the first article a Microsoft employee mentions

<--------------------->

There’s a known issue with some of the old display drivers.  <I believe the issue I am facing is related to this area>

Display drivers report some of their capabilities upon load. In previous Windows versions this reported data wasn’t used or verified. Because of that, some of the old versions of the legacy display driver may report invalid data and it would be ignored. Starting with Windows 10 1903 RDP uses this data to initialize the session. 

The best option is to install an updated display driver from the hardware manufacturer. If the new version is not available, you can workaround this by disabling the problematic driver in the device manager.

Our team has identified the issue and we are currently verifying the fix that will dynamically switch to the software renderer if the problematic driver is detected.

I will this thread when the fix will be included to the Windows Insider release.

<---------------------->

Further testing in my environment has shown that machines without Intel integrated graphics are also showing the problem.

In the second article it mentions a change to the RDP driver area

<--------------------->

XDDM-based remote display driver: Starting with this release the Remote Desktop Services uses a Windows Display Driver Model (WDDM) based Indirect Display Driver (IDD) for a single session remote desktop. The support for Windows 2000 Display Driver Model (XDDM) based remote display drivers will be removed in a future release. Independent Software Vendors that use XDDM-based remote display driver should plan a migration to the WDDM driver model. For more information on implementing remote indirect display driver ISVs can reach out to *** Email address is removed for privacy ***.

<--------------------->

As a workaround on all of my affected machines I have used Group Policy Editor to set

Local Computer Policy

 Computer Configuration

  Administrative Templates

   Windows Components

    Remote Desktop Service

     Remote Desktop Session Host

      Remote Session Environment

       Use WDDM graphics display driver for Remote Desktop Connections

to DISABLED

This forces RDP to use the old (and now deprecated XDDM drivers)

After rebooting, behaviour returns to normal and after disconnecting from an RDP session the RDP host (target machine) no longer shows DWM.EXE consuming CPU.

This isn't a long term fix (to rely on a deprecated feature). I also don't understand why only a limited number of users are affected, but for now, I'm up and running again, and hoping for a Microsoft fix.

Was this discussion helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this discussion?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this discussion?

Thanks for your feedback.

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

I have this problem too. Hope Microsoft can fix it soon.

40 people found this reply helpful

·

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Same issue here

If the host is left alone with dwm.exe taking up one full core it will eventually crash and log out the session

Intel 4770K with Asus Sabertooth Z87 motherboard using integrated intel gpu for the host (display driver 20.19.15.5063)

Intel 3770K with Asus Sabertooth Z77 motherboaed using nvidia gpu for the client

Faulting application name: dwm.exe, version: 10.0.18362.1, time stamp: 0x6468b8f9

Faulting module name: dwmcore.dll, version: 10.0.18362.1, time stamp: 0xb9c883ae

Exception code: 0xc00001ad

Fault offset: 0x000000000015bada

Faulting process id: 0x1cf4

Faulting application start time: 0x01d5118f548421db

Faulting application path: C:\WINDOWS\system32\dwm.exe

Faulting module path: C:\WINDOWS\system32\dwmcore.dll

Report Id: 8db71ccd-573e-41f5-8ca8-a2954c58ee5a

Faulting package full name: 

Faulting package-relative application ID: 

12 people found this reply helpful

·

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

I may be having a similar issue on a Lenovo laptop. I have 1903 on other hardware and works fine. I use this Lenovo laptop that has both Intel and nVidia GPUs running the latest drivers available for both. As far as I can tell, the system is fully up to date. However, if I RDP to this laptop, at some point the RDP session terminates and my user logged out. Looking at the event log, I see DWM.EXE has crashed two to three times with connected devices crashing events as well.

I have not monitored DWM.EXE's memory and CPU footprint. I just know I've updated to 1903 on this laptop at least 7 times and each time, I've had to revert back to 1809 as this issue is destructive to productivity. It's also the only system I have that isn't running 1903 at this time.


4 people found this reply helpful

·

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

The instructions in the initial post fixed my issues. Let's hope the legacy RDP stays as long as modern RDP has issues

It does require Windows 10 Pro. A home version lacks the required policy editor

7 people found this reply helpful

·

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

million thanks, the suggestion of using policy editor to force XDDM solved my issue. My machine in question is a Macmini late 2014 which has Intel GPU. Before this fix, a disconnected RDP session takes up 30% of the CPU, now it is back to normal as previous version of Windows 7/10/server.

9 people found this reply helpful

·

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Thank you for posting this fix, worked as a charm.

I have been suffering this issue for months. I did successfully find the basic display driver workaround but didn't go further as you did. Great troubleshooting!

win10 1903 + i5 3470 hd graphic, tried various intel display drivers.

7 people found this reply helpful

·

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

tried to do this workaround, but after reboot and after a fraction of second of showing off lock screen, screen turn all light blue (not BSOD) without no option of interaction.

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

Have the same issue with my old Lenovo Thinkpad X-220 that I uses as a server at home. To monitor the issue I use WSL to ssh into the target (RDP host/server/X-220) machine and list the dwm.exe processes:

$ alias showdwm='/mnt/c/Windows/System32/tasklist.exe /v | awk "/dwm/ {print \$1, \$8, \$9, \$10, systime()}"

### dwm processes (one) before the RDP session. You can see that DWM-3 is "silent" and consumes no CPU

$ showdwm

dwm.exe Window Manager\DWM-3 0:00:00 1564384094

$ showdwm

dwm.exe Window Manager\DWM-3 0:00:00 1564384118

### dwm processes during RDP session. Both processes are silent as can be seen by sampling the tasklist with some time in-between (here 27 seconds)

$ showdwm

dwm.exe Window Manager\DWM-3 0:00:00 1564384161

dwm.exe Window Manager\DWM-1 0:00:01 1564384161 

$ showdwm

dwm.exe Window Manager\DWM-3 0:00:00 1564384188

dwm.exe Window Manager\DWM-1 0:00:01 1564384188

### dwm processes after the RDP session ends. Now DWM-1, which was the process initated with RDP, begins to consume CPU. 13 seconds CPU consumption during 13 seconds of real time. Corresponds to 25% consumption on the machine. Fan spins up.

$ showdwm

dwm.exe Window Manager\DWM-3 0:00:00 1564384207

dwm.exe Manager\DWM-1 0:00:06 N/A 1564384207

$ showdwm

dwm.exe Window Manager\DWM-3 0:00:00 1564384220

dwm.exe Manager\DWM-1 0:00:19 N/A 1564384220

### My workaround, kill all dwm.exe processes:

$ alias killdwm='/mnt/c/Windows/System32/taskkill.exe /IM "dwm.exe" /F'

$ killdwm
SUCCESS: The process "dwm.exe" with PID 10972 has been terminated.
SUCCESS: The process "dwm.exe" with PID 9648 has been terminated.

### Now we are back to one, silent, process
$ showdwm 
dwm.exe Window Manager\DWM-3 0:00:00 1564384271
$ showdwm 
dwm.exe Window Manager\DWM-3 0:00:00 1564384279

I don't know if that could be a solution, but why not terminate the RDP initiated dwm.exe process when the RDP session terminates? It seems at least for me that it is that process that causes the high CPU consumption. 

 

3 people found this reply helpful

·

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

@beos59,

A valid approach - you could define a new Task Scheduler job with

General

- Run whether user is logged on or not / Run with Highest privileges

Trigger

- On remote disconnect from any user session

Action

- Start a program

- c:\windows\system32\taskkill.exe

- Add arguments "/IM dwm.exe /F"

etc

You get a few warning events in the event log (Desktop Window Manager process has exited), but other than that there doesn't appear to be any side effects.

I do wish Microsoft would recognize this problem and fix it !

5 people found this reply helpful

·

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

As a workaround on all of my affected machines I have used Group Policy Editor to set

Local Computer Policy

 Computer Configuration

  Administrative Templates

   Windows Components

    Remote Desktop Service

     Remote Desktop Session Host

      Remote Session Environment

       Use WDDM graphics display driver for Remote Desktop Connections

to DISABLED

This forces RDP to use the old (and now deprecated XDDM drivers)

After rebooting, behaviour returns to normal and after disconnecting from an RDP session the RDP host (target machine) no longer shows DWM.EXE consuming CPU.

This isn't a long term fix (to rely on a deprecated feature). I also don't understand why only a limited number of users are affected, but for now, I'm up and running again, and hoping for a Microsoft fix.

You are a legend this worked for me. Before I found this thread I was closing out of the session then using Anydesk to login back into windows just to stop the issue. The crazy thing is Anydesk would lock up after the login but it stopped CPU 1 going to 100%.

20 people found this reply helpful

·

Was this reply helpful?

Sorry this didn't help.

Great! Thanks for your feedback.

How satisfied are you with this reply?

Thanks for your feedback, it helps us improve the site.

How satisfied are you with this reply?

Thanks for your feedback.

* Please try a lower page number.

* Please enter only numbers.

* Please try a lower page number.

* Please enter only numbers.

 
 

Discussion Info


Last updated February 8, 2023 Views 28,544 Applies to: