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.
Please also mark the comments that contributed to the solution of the article
Content-ID: 485460
Url: https://administrator.de/contentid/485460
Printed on: November 6, 2024 at 12:11 o'clock
19 Comments
Latest comment
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.
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
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.
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
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.
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
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.