Seit Win10 1903(?) hohe CPU-Last von DWM.exe nachdem RDP-Session beendet wurde

Gast #5876018
Lesenswert?

Ich habe so einen komischen Effekt auf meinem System entdeckt, der mich 
seit 1903 nervt. Zumindest ist er mir vorher nicht aufgefallen.

- Das System ist idle, laut Taskmanager auch tatsächlich im Leerlauf.
- Nun öffne ich von einem anderen Windows-10-System eine 
Remote-Desktop-Verbindung. Ich verwende das gleiche Benutzerkonto. Mir 
ist wichtig, dass ich auf die laufenden Anwendungen Zugriff nehmen kann. 
Damit hatte ich über verschiedene Windows-Versionen hinweg auch noch nie 
Probleme.
- Weiterhin ist das Zielsystem im Leerlauf.
- Ich beende die Remote-Desktop-Session (schließe das Fenster), logge 
mich aber auf dem Zielsystem nicht lokal ein (der Sperrbildschirm ist 
also zu sehen).
- Nun merke ich, dass der Lüfter langsam hoch dreht.
- Nach einiger Zeit logge ich mich wieder ein und sehe im Taskmanager 
nach: DWM.exe hat Unmengen an CPU-Zeit gefressen! Interessanterweise ist 
das System nach dem Einloggen aber wieder idle, d.h. das Problem ist gar 
nicht so einfach zu detektieren. Im Diagramm oben sieht man den Effekt 
nach dem Beenden der RDP-Session aber.

Natürlich habe ich nach Viren gescannt. Das System ist clean und die 
DWM.exe ist tatsächlich die originale Version von MS.
Über Google fand ich heraus, dass eine aktive "Bildschirmlupe" sowas 
bewirken kann. Ist aber hier nicht der Fall. Wie gesagt tritt die Last 
auch erst nach dem RDP-Beenden auf.

Wenn ich den Benutzer abmelde (egal, ob per RDP oder lokal), bleibt das 
System im Leerlauf. Ebenso im reinen Sperrbildschirm (Strg-Alt-Entf).

Jemand eine Idee?
Angehängte Dateien:
Gast #5876063
Lesenswert?

Das Killen bringt keine Lösung, da DWM sofort neu gestartet wird. Und 
wenn das Problem akut ist (nach dem Beenden der RDP-Session, aber VOR 
dem neuen Einloggen), kann man ja nichts killen. Dazu müsste man sich ja 
einloggen und dann killen und dann wieder die Session beenden... und 
dann frisst der neue DWM ja wieder CPU. Die einzige Lösung ist das 
lokale Einloggen. Aber das läuft ja dem Sinn von RDP entgegen.

Ich weiß auch nicht, ob das ein allgemeines Windows-10-Problem ist. 
Eventuell habe nur ich das? Eventuell probiert es noch mal jemand anders 
aus. Ich habe eine integrierte Intel-Grafik und der Treiber ist aktuell. 
Hatte ich noch vergessen, zu schreiben.
Gast #5876188
Lesenswert?

Horst schrieb:
> Einfach gesagt: RDP ist unsicherer schrottiger Müll. In letzter Zeit
> häufen sich die Meldungen dazu nur so. Du solltest dir dringend eine
> Alternative suchen.

Das ist ja wohl die dämlichste Aussage seit langem. Zeig mir mal unter 
Linux oder OSX eine Remote-Desktop Variante die auch nur annähernd mit 
der MS Implementation mithalten kann. Da ist Schicht im Schacht. Alles 
was unter Linux oder OSX über vnc oder ähnliche Protokolle gemacht wird 
ist schlechter. Das geht mal um remote etwas zu konfigurieren aber nicht 
zum dauerhaften Arbeiten. Leider, weil das ist eine der Gründe, dass 
sich in der Industrie Windows so harnäckig hält. Und kommt nicht mit 
sowas wie NoMaschine, das ist auch nur aufgebohrter VNC Mist.

Und wegen der Unsicherheit. Es ist ja wohl keiner gezwungen den RDP-Port 
offen ins Internet zu hängen. Über die vielen Möglichkeiten ver VPN oder 
andere Tunnel brauche ich sicher nicht zu philosophieren.
Gast #5876322
Lesenswert?

Ne, im Ereignisprotokoll ist nichts zu sehen, was auf ein Problem 
hindeuten könnte.

Die üblichen Tests wie

dism /online /cleanup-image /checkhealth
dism /online /cleanup-image /scanhealth
sfc /scannow
chkdsk c: /f

führten auch keine Probleme zutage.

Ich habe auch keine "Diashow" oder Ähnliches auf dem Sperrbildschirm 
laufen, auch keinen Bildschirmschoner.
Gast #5876350
Lesenswert?

Habe eben einen zweiten (Ziel-)Rechner getestet. Selbes Phänomen! Wenn 
jemand von euch die Möglichkeit hat, das auch mal zu testen, wäre ich 
dankbar. Eventuell ist es doch ein allgemeines Windows-10-Problem...
Gast #5876876
Lesenswert?

bla schrieb:
> DWM.exe hat Unmengen an CPU-Zeit gefressen!

PC-Magazin meinte: Der Desktopfenster-Manager (dwm.exe) verarbeitet 
diese Vorgaben zu einem Gesamtbild und gibt es auf dem Display aus. In 
der Regel verursacht der Desktopfenster-Manager keine nennenswerte 
Systemlast. Die CPU-Last liegt meistens unter einem Prozent, der 
RAM-Verbrauch unter 100 Megabyte. Geht es auf Ihrem Computer wilder zur 
Sache, dann stellen Sie als erstes sicher, dass die Treiber für die 
Grafikkarte aktuell sind.

Mal Daten der benutzten DWM.exe genauer verglichen? Datum, Dateigröße?
Noch andere Treiberprobleme?
Gast #5876895
Lesenswert?

Grafiktreiber ist aktuell. Habe testweise auch schon andere Versionen 
installiert, ohne Unterschied. Wie gesagt ist auch ein zweiter (von 
zwei) getesteten Rechnern betroffen. Würde mich nicht wundern, wenn das 
ein allgemeiner Bug wäre.
Gast #5876897
Lesenswert?

Wenn die dwm.exe irgendwas benutzen muß, was seit dem Abbruch der 
Verbindung weg ist, könnte sie unheimlich "fleißig" werden. Das würde 
auf einen Programmfehler/Virus hindeuten? Deswegen Dateigröße und Datum 
mal genauer ansehen.
Gast #5878030
Lesenswert?

That's exactly the same problem, indeed! Thank you for posting that.

In the mean time I opened an issue in the international forums:
https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/after-exiting-a-remote-desktop-session-cpu-load/e21e7da0-9a64-4a14-a671-b7cb1b61f66e


A temporary solution is to end the connection using (run as admin on the 
remote system):

tscon 1 /dest:console

This will log in the original user, so instead of the lock screen the 
desktop is displayed.
Gast #5895843
Lesenswert?

Ich kann den Fehler nur bestätigen liegt an der Windows Version 1903. 
Habe 2 idenische Systeme mit frischer Windows 10 installation. Einmal 
1903 und einmal 1809. Der beschriebene Fehler mit der Hohen CPU Last 
nach beendigung der RDP Sitzung tritt nur bei dem 1903 System auf.

Gruß Tobi
Beitrag #5908198 wurde von einem Moderator gelöscht.
Gast #5930361
Lesenswert?

Gast #5930956
Lesenswert?

Bei MS scheint keiner die Feedbacks zu lesen. Habe schon mehrere mit 
definitiven Bugs und genauen Reproduktionsbeschreibungen (auch diesen 
vor vielen Wochen) gepostet, aber nix passiert. Also gar nichts. MS ist 
völlig überfordert mit Win10. Ich kann nur davon abraten, die 
"aktuellen" Versionen zu verwenden. Also jetzt z.B. maximal die 1809, 
aber keinesfalls die 1903 installieren.
Gast #5936703
Lesenswert?

Hallo,

für die Ersthilfe ... folgendes durchführen :

Gruppenrichtlinie bearbeiten -> Administrative Vorlagen -> 
Windows-Komponenten -> Remotedesktopdienste -> 
Remotedesktopsitzungs-Host -> Umgebung für Remotesitzung -> 
WDDM-Grafiktreiber für Remotedesktopverbindungen verwenden -> von "Nicht 
konfiguriert" auf "Deaktiviert" setzen

Dann sollte das Problem erst einmal behoben sein, bis Microsoft handelt.

LG
#5937844
Lesenswert?

Ich kann den Bug auch bestätigen. Windows 10 1903 auf einem NUC8i7. Mit 
aktiver RDP Session 2,4 Watt im Idle, nach Beenden der Session 8 Watt.

XBooSTeR schrieb:
> für die Ersthilfe ... folgendes durchführen :
>
> Gruppenrichtlinie bearbeiten -> Administrative Vorlagen ->
> Windows-Komponenten -> Remotedesktopdienste ->
> Remotedesktopsitzungs-Host -> Umgebung für Remotesitzung ->
> WDDM-Grafiktreiber für Remotedesktopverbindungen verwenden -> von "Nicht
> konfiguriert" auf "Deaktiviert" setzen
>
> Dann sollte das Problem erst einmal behoben sein, bis Microsoft handelt.

Hmm...mit welchen Nebenwirkungen ist denn dann zu rechnen?
Gast #5951987
Lesenswert?

Habe das Selbe Problem, zudem haben mir Monitoring Systeme eine 
Plötzliche CPU last von über 50% angezeigt sobald die RDP-Verbindung 
getrennt wurde. Obwohl während der bestehenden Verbindung die CPU bei 2% 
rumtümpelte und in den Ereignissen nichts auffälliges zu finden war 
außer, dass irgend ein Protokoll gelöscht wurde(daher war meine erste 
Vermutung viel schlimmer)

"Umstellen auf Volltonfarbe hat geholfen" hat nicht geholfen

die Anleitung Christian R jedoch hat super funktioniert.
Danke

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren