19
RDP auf Win10 1903 - XDDM vs. WDDM
Moin Kollegen.
Vielleicht habt Ihr den Bug noch gar nicht bemerkt: Wenn man sich per RDP zu Win10 v1903 verbindet und die Sitzung trennt, ohne sich abzumelden, dann hängt sich der Prozess dwm.exe auf und lastet einen CPU-Kern vollkommen aus. Dies gilt nur für 1903 und auch die letzten Updates von Dienstag haben es nicht behoben. Man findet seit Juni Forenposts wie dieses:
https://www.reddit.com/r/Windows10/comments/c0agnb/1903_dwmexe_goes_to_1 ...
Dort steht auch ein Workaround, der funktioniert:
Soweit so gut. Kann mir jemand zufällig sagen, was der XDDM-Treiber schlechter macht, als der WDDM, ohne mich mit Dokulinks zu bombardieren?
Ich frage also nach Praxiserfahrungen mit dieser Einstellung.
Ich würde diesen Workaround eh nicht generell deployen, sonden nur auf ein paar VMs, die von Entwicklern benutzt werden, die sich nicht abmelden möchten, sondern immer mit "trennen" arbeiten, dennoch wüsste ich gerne, ob Nebeneffekte zu erwarten sind, die man bei 2D in Entwicklungsumgebungen bemerkt.
Vielleicht habt Ihr den Bug noch gar nicht bemerkt: Wenn man sich per RDP zu Win10 v1903 verbindet und die Sitzung trennt, ohne sich abzumelden, dann hängt sich der Prozess dwm.exe auf und lastet einen CPU-Kern vollkommen aus. Dies gilt nur für 1903 und auch die letzten Updates von Dienstag haben es nicht behoben. Man findet seit Juni Forenposts wie dieses:
https://www.reddit.com/r/Windows10/comments/c0agnb/1903_dwmexe_goes_to_1 ...
Dort steht auch ein Workaround, der funktioniert:
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.
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.
Soweit so gut. Kann mir jemand zufällig sagen, was der XDDM-Treiber schlechter macht, als der WDDM, ohne mich mit Dokulinks zu bombardieren?
Ich frage also nach Praxiserfahrungen mit dieser Einstellung.
Ich würde diesen Workaround eh nicht generell deployen, sonden nur auf ein paar VMs, die von Entwicklern benutzt werden, die sich nicht abmelden möchten, sondern immer mit "trennen" arbeiten, dennoch wüsste ich gerne, ob Nebeneffekte zu erwarten sind, die man bei 2D in Entwicklungsumgebungen bemerkt.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 485460
Url: https://administrator.de/contentid/485460
Ausgedruckt am: 22.11.2024 um 11:11 Uhr
19 Kommentare
Neuester Kommentar
Danke für den Hinweis, ich habe gerade genau das beobachtet und da das System nur einen CPU Kern besitzt war auch über die Konsole nix mehr zu reißen. ;)
Dann muss die Kollegin mal brav abmelden und gut ist.
Dann muss die Kollegin mal brav abmelden und gut ist.
Möglicherweise liege ich daneben. Ich hatte das Thema vor einem Monat unter anderem Kontext im Blog-Beitrag Windows 10 V1903: Remote Desktop zeigt Black-Screen behandelt. Beim WDDM-Treiber wertet Microsoft erstmals bestimmte Eigenschaften, die der Treiber liefert, aus und setzt damit den RDP-Client auf. Dabei liefern manche Treiber aber nicht initialisierte Werte, so dass RDP Probleme bereitet (Hänger, Black Screen etc.). Durch das Erzwingen des alten XDDM-Treibers scheint diese Auswertung wegzufallen (da hat man wohl nix neu implementiert). Aber möglicherweise liege ich daneben - - aber die Leute bestätigen mir in Rückmeldungen, dass es auch wirkt. Microsoft will dieses Problem aber irgendwann fixen - wobei es wohl nur ältere Grafiktreiber, vorwiegend auf Notebooks, trifft.
Danke Günter. Ich suche jedoch nach Erfahrungen mit XDDM.
Irgendwelche Nachteile wird es ja haben, dass es nicht mehr Standard bei RDP auf 1903 ist.
PS: Anzeigetreiber sind hier jeweils topaktuell und es tritt auch bei VMs auf.
Irgendwelche Nachteile wird es ja haben, dass es nicht mehr Standard bei RDP auf 1903 ist.
PS: Anzeigetreiber sind hier jeweils topaktuell und es tritt auch bei VMs auf.
Gibt jede Menge Performance- und Stabilitätsgründe gegen XDDM. Wird deine Entwickler aber eher nicht überzeugen.
Ich glaube für dich dürfte am ehesten der Security Aspekt relevant sein:
Quelle: https://docs.microsoft.com/en-us/windows/win32/direct3d9/xpdm-vs-wddm
Trifft sowohl XPDM alsauch XDDM.
Grüße,
Philip
Ich glaube für dich dürfte am ehesten der Security Aspekt relevant sein:
Differences between XPDM and WDDM:
On WDDM, Session 0 Isolation ensures that a service does not have access to any user desktop as a security measure, therefore, a Direct3D 9 HAL device is never available from a Windows service.
On WDDM, Session 0 Isolation ensures that a service does not have access to any user desktop as a security measure, therefore, a Direct3D 9 HAL device is never available from a Windows service.
Quelle: https://docs.microsoft.com/en-us/windows/win32/direct3d9/xpdm-vs-wddm
Trifft sowohl XPDM alsauch XDDM.
Grüße,
Philip
Was sind deine Praxiserfahrungen mit dieser Einstellung?
Nur danach frage ich
Nur danach frage ich
Ja, ist allerdings Jahre her und war auf Windows 7 und 8.1 Workstations im Zusammenhang mit Geforce 450 bzw. Quadro 4000 Karten und der Software ObjetStudio 9.1.x und 9.2.x.
Remoting via RDP funktionierte nur mit dem XDDM Workaround, sonst crashte der ObjetStudio Renderer samt Platzierungssoftware (JobManager, und damit der Druckjob, lief wenigsterns weiter, wenn auch unsichtbar...).
Das Problem war, dass der Renderer auch nach der nächsten lokalen Anmeldung weiterhin 100% auf der CPU lief, und nicht wieder die GPU verwendete.
Wir hatten es dann gelöst, indem wir auf RDP fürs Remoting verzichteten, und für diese Workstations auf HP RGS umsattelten.
Nachstellen ist für mich nicht mehr möglich, AG hat sich seither geändert.
Kommt für deine Anwendung nur eben leider nicht in Frage.
Was sind denn deine Erfahrungen mit XDDM? Es geht ja nicht darum, warum Du XDDM genommen hast.
Lief danach alles zur Zufriedenheit?
Lief danach alles zur Zufriedenheit?
3D Performance vom Softwarerenderer war bei XDDM halt grottig. Und der Renderer riss ganz gern den Grafiktreiber mit in den Abgrund. Was bei XDDM einen Bluescreen verursachte.
Bei WDDM crashte einfach nur die Applikation und der Grafiktreiber wurde erneut initialisiert. Auch unschön, aber der JobManager Prozess lief weiter, und damit war der Druckprozess, der seit 2 Wochen an dem Teil druckte nicht kaputt.
Bei einer stabilen 2D Anwendung sehe ich da jetzt zugegeben eher weniger Problem.
Bei WDDM crashte einfach nur die Applikation und der Grafiktreiber wurde erneut initialisiert. Auch unschön, aber der JobManager Prozess lief weiter, und damit war der Druckprozess, der seit 2 Wochen an dem Teil druckte nicht kaputt.
Bei einer stabilen 2D Anwendung sehe ich da jetzt zugegeben eher weniger Problem.
Hallo DWW,
ich habe das gestern mit einer VM auf Azure erlebt, wobei ein erneutes Verbinden gar nicht mehr möglich war. Heute habe ich mal auf Verdacht den Blur-Effekt des Start-Screens abgeschaltet und es ging (wobei das bei der VM über ein lahmes VPN generell sehr langsam ist und ich nicht sicher bin, was davon nun Fehlfunktion ist). Kann es sein, dass schon diese Design-Einstellung Besserung bringt?
Grüße
Richard
ich habe das gestern mit einer VM auf Azure erlebt, wobei ein erneutes Verbinden gar nicht mehr möglich war. Heute habe ich mal auf Verdacht den Blur-Effekt des Start-Screens abgeschaltet und es ging (wobei das bei der VM über ein lahmes VPN generell sehr langsam ist und ich nicht sicher bin, was davon nun Fehlfunktion ist). Kann es sein, dass schon diese Design-Einstellung Besserung bringt?
Grüße
Richard
Hi. Guck ich mir bei Gelegenheit Mal an.
Habe nun getestet Blur/Acrylic abzuschalten - hier hat das keine Verbesserung gebracht.
Aber XDDm läuft soweit gut und der Workaround ist ok.
In Microsofts Forum haben über 10.000 Leute angeklickt, dass sie das selbe Problem haben. Wenn Sich Microsoft dann nicht rührt, weiß ich auch nicht. https://answers.microsoft.com/en-us/windows/forum/windows_10-performance ...
@psannz Ich habe deine Erfahrngen noch nicht ganz einordnen können. WDDM wird ja erst bei Win10 v1903 erzwungen. Du sprichst von Win7/8.1 und da gab es die Policy noch gar nicht.
Aber XDDm läuft soweit gut und der Workaround ist ok.
In Microsofts Forum haben über 10.000 Leute angeklickt, dass sie das selbe Problem haben. Wenn Sich Microsoft dann nicht rührt, weiß ich auch nicht. https://answers.microsoft.com/en-us/windows/forum/windows_10-performance ...
@psannz Ich habe deine Erfahrngen noch nicht ganz einordnen können. WDDM wird ja erst bei Win10 v1903 erzwungen. Du sprichst von Win7/8.1 und da gab es die Policy noch gar nicht.
Mal ganz abwegig, ich könnte das Problem ja wie oben geschrieben auch nachvollziehen, nach neuster Beobachtung aber nur an einem System was keinen Standardgateway hat und somit kein Internet.
Hmm...?
Hmm...?
Salut, grabe das hier noch mal aus, da ich gerade die Changelogs durchschaue:
Quelle: https://support.microsoft.com/en-us/help/4512941
Addresses an issue that displays a black screen when you use Remote Desktop to connect to a machine running Windows 10, version 1903.
Danke, wollte es auch gerade nachtragen. Bevor jemand das Update installiert, lese er
Windows 10 V1903: Cortana erzeugt hohe CPU-Last sowie kaputte Suche durch August 2019-Updates
Ergänzung: Im englischsprachigen Blog habe ich eine Benutzerrückmeldung, dass Update KB4512941 das dwm.exe-Lastproblem bei ihm nicht behoben habe.
Windows 10 V1903: Cortana erzeugt hohe CPU-Last sowie kaputte Suche durch August 2019-Updates
Ergänzung: Im englischsprachigen Blog habe ich eine Benutzerrückmeldung, dass Update KB4512941 das dwm.exe-Lastproblem bei ihm nicht behoben habe.
Zitat von @kgborn:
Windows 10 V1903: Cortana erzeugt hohe CPU-Last sowie kaputte Suche durch August 2019-Updates]
Würde das nicht zu hoch aufhängen.Windows 10 V1903: Cortana erzeugt hohe CPU-Last sowie kaputte Suche durch August 2019-Updates]
Ich habe auf allen 1903ern darauf verzichtet die Vorabversionen des Updates zu installieren und habe nun auf die finale Version gewartet.
Bislang auf 10 Systemen ausgerollt und keine Auffälligkeiten diesbezüglich.
Wird morgen dann für alle freigegeben.
Das Update brachte hier keine Veränderung bezüglich der CPU-Last. Bei Euch etwa?
1
Also der XDDM Workaround funktioniert zwar bei mir, aber so kann ich nicht die volle Monitorauflösung verwenden. Sehe links und rechts schwarze Balken, obwohl die RemoteFX Karte mit maximal möglicher Auflösung (3840 x 2160) installiert ist.
Habe das kummulative Oktober 2019 Update auf dem Client und RDP-Ziel (beides Windows 10 1903) installiert. WDDM geht leider immer noch nicht... schwarzer Bildschirm.
Ich kann mich auf dem Hyper-V Host mit dem RDP-Ziel verbinden und sehe da die Karte als "Microsoft RemoteFX-Grafikgerät - WDDM" mit einem Treiber von 2006.
Dxdiag sagt dass Driect3D etc. unterstützt wird. die WDDM Treiber Version wird mit 1.3 angegeben.
Mein Hyper-V Host sagt für die Karte aber WDDM 2.1.
Ist das mein Problem? Kann Windows 10 RDP WDDM 1.3?
Danke im Voraus schon mal
Habe das kummulative Oktober 2019 Update auf dem Client und RDP-Ziel (beides Windows 10 1903) installiert. WDDM geht leider immer noch nicht... schwarzer Bildschirm.
Ich kann mich auf dem Hyper-V Host mit dem RDP-Ziel verbinden und sehe da die Karte als "Microsoft RemoteFX-Grafikgerät - WDDM" mit einem Treiber von 2006.
Dxdiag sagt dass Driect3D etc. unterstützt wird. die WDDM Treiber Version wird mit 1.3 angegeben.
Mein Hyper-V Host sagt für die Karte aber WDDM 2.1.
Ist das mein Problem? Kann Windows 10 RDP WDDM 1.3?
Danke im Voraus schon mal
Ich nutze hier kein RemoteFX - keine Ahnung.
Mit Auflösungen bis QHD (2560x1440) habe ich hier keine Probleme und keine schwarzen Balken. Höhere habe ich nicht zum Test zur Verfügung.
Mit Auflösungen bis QHD (2560x1440) habe ich hier keine Probleme und keine schwarzen Balken. Höhere habe ich nicht zum Test zur Verfügung.
Es gibt einen ganz signifikanten Nachteil. Ich verstehe zwar nicht warum, aber nach der Deaktivierung von WDDI tritt Folgendes auf:
Zuerst bemerkt man nichts. Die Grafik hackt bei connections via RDP gaanz leicht, aber kaum spürbar. Wenn man aber länger als 15 Minuten arbeitet, wird diese Verzögerung aus irgendeinem Grund massiv: Wenn man tippt, verzögert das Display alle 3-4 Sekunden um über eine halbe Sekunde. Komplett unbrauchbar. Brauchte einen rebuild des Win10 PC's auf welchen Remote zugegriffen wird, um überhaupt zu merken woran es liegt. Erst als mir (nach dem Rebuild) die schwarze Box um den Mauszeiger herum wieder auffiel ist mir eingefallen wie ich es "behoben" hatte.
Also kleiner Gratistipp - auf keinen Fall einfach mal das "Use WDDM graphics display driver for Remote Desktop Connections" - setting ändern.
Zuerst bemerkt man nichts. Die Grafik hackt bei connections via RDP gaanz leicht, aber kaum spürbar. Wenn man aber länger als 15 Minuten arbeitet, wird diese Verzögerung aus irgendeinem Grund massiv: Wenn man tippt, verzögert das Display alle 3-4 Sekunden um über eine halbe Sekunde. Komplett unbrauchbar. Brauchte einen rebuild des Win10 PC's auf welchen Remote zugegriffen wird, um überhaupt zu merken woran es liegt. Erst als mir (nach dem Rebuild) die schwarze Box um den Mauszeiger herum wieder auffiel ist mir eingefallen wie ich es "behoben" hatte.
Also kleiner Gratistipp - auf keinen Fall einfach mal das "Use WDDM graphics display driver for Remote Desktop Connections" - setting ändern.
