[English]Benutzer von Windows 10, die auf das Mai 2019 Update umgestiegen sind und die Remote Desktop-Funktion für Remote-Sitzungen verwenden, leiden ggf. darunter, dass nur noch schwarze Fenster angezeigt werden. Trifft nur Nutzer in Unternehmensumgebungen wo Remote Desktop zur Verfügung steht und tritt nur bei älterer Hardware auf. Hier einige Informationen und Hintergründe.
Das Problem plagt Windows 10-Nutzer schon länger
Geht man mit den Begriffen “windows 10 remote desktop black screen” im Internet auf die Suche, findet man Treffer bis 2017 und früher. Nimmt man noch den Begriff V1903 hinzu, engt das die Treffer auf das Windows 10 Mai 2019 Update ein. Im englischsprachigen Microsoft Answers-Forum habe ich diesen Thread von Ende Mai 2019 gefunden.
Windows 10 1903 (May update) black screen with Remote Desktop
I upgraded my secondary machine from 1809 to 1903. When I access it now using Remote Desktop all I get is a black screen in the RDP windows. I then upgraded my primary machine to 1903 hoping that would help, but no. Fortunately I also have GoToAssist installed so I was able to log into the secondary machine that way and checked for updates, still no help. Finally I reverted it back to 1809 and Remote Desktop once again works. I could keep using GoToAssist but RDP over my local LAN is much faster.
As long as this version as been (more or less) gold before going public, I can’t possibly be the first one with this issue. It’s no big deal to me that my secondary is running 1809, it’s primarily a file server, but upgrading would be nice.
Granted, that secondary system is an older Core2 Quad, but at 3.3GHz and 8GB of memory and a SSD, it’s plenty fast enough. I suppose I could try a different video card, but it shouldn’t be necessary for a feature update.
Anyone have some insight into why RDP isn’t working. I’ve already been through all the „guesses“.
Nach dem Upgrade auf Windows 10 V1903 stand der Benutzer vor dem Problem, dass sein Remote Desktop nur noch ein schwarzes Fenster zeigte. Er hat es dann mit mehreren Maschinen erfolglos versucht. Bei MS Answers muss man leider das ‘Grundrauschen an nutzlosen Hinweisen’ der ‘Independat Advisors’ rausfiltern. Ich entnehme dem Thead aber, dass der Nutzer nicht alleine war. Es gibt zwar Hinweise auf ältere Display-Treiber, wo ein Update helfen kann.
Und noch was: Ich bin auf den Blog-Beitrag Remote Desktop Black screen in Windows 10 1903 update vom 1. Juni 2019 gestoßen, der im Surface Tablet-Blog erschienen ist. Dort hat ein Nutzer den Effekt beim Surface Pro 5 beschrieben. Dort gibt der Autor an, dass ältere Hardware wie z. B. AMD Radeon R7 350X oder der Intel Q45/Q43 Grafikchipsatz nicht mit Windows 10 V1903 kompatibel seien – es hakt beim aktuellen Treiber der Display-Adapter. Ergebnis: Die Remote Desktop-Sitzung zeigt nur noch einen schwarzen Bildschirm, während Maus und Tastatur die Steuerung übernehmen. Man kann dann nur noch den Prozess per Task Manager beenden.
Kennt Microsoft seine Hardware nicht? Es ist schon doof, wenn RDP unter Windows 10 V1809 funktioniert, die Leute aber nach dem Upgrade auf V1903 in ein schwarzes Loch blicken – da blinkt dann nicht mal mehr ‘Windows as a Service’ hervor – liegt sozusagen hinter dem Ereignishorizont von Microsoft, wo man nichts mehr wahrnimmt, was dort passiert.
Microsoft bestätigt und erklärt das Problem
Ich habe mal schnell auf der Statusseite von Windows 10 V1903 nachgesehen – da ist nichts von diesem Problem zu finden. Nun berichtet Windows Report, dass Microsoft-Mitarbeiter Denis Gundarev bestätigte, dass es sich um ein bekanntes Problem handele.
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.
Auch dort werden veraltete Grafiktreiber als Ursache angegeben. Der Grund, warum es jetzt zu einem schwarzen Bildschirm kommt, wird auch erklärt. Display-Treiber melden auf Anfrage einige ihrer Fähigkeiten beim Laden zurück. In früheren Windows-Versionen wurden diese gemeldeten Daten nicht verwendet oder verifiziert. Aus diesem Grund können einige der alten Versionen des alten Anzeigetreibers ungültige Daten melden, die ignoriert werden. Ab Windows 10 1903 verwendet RDP diese Daten zur Initialisierung der Sitzung.
Microsoft erklärte, dass seine Entwicklung an einer dauerhaften Lösung arbeiten. In der Zwischenzeit sollten sich Betroffene an Ihren Hardwarehersteller wenden, um Ihren Anzeigetreiber zu aktualisieren. Von Windows Report gibt es diese alte Anleitung aus 2018, die mögliche Fixes beschreibt. Immer schon, wenn Probleme auftreten, die wenigstens bekannt sind. Jemand von euch betroffen?
Workaround: XDDM-Treiber erzwingen
Ergänzung: Im Eingangs verlinkten englischsprachigen Blog-Beitrag hat ein Nutzer aus Hongkong eine Lösung beschrieben. Die Ursache hängt am XDDM versus WDDM-Display Driver Model. Die haben per Gruppenrichtlinie die Verwendung der alten XDDM-Grafiktreiber bei Remote Desktop-Verbindungen erzwungen und konnten arbeiten.
- Rufen Sie dazu gpedit.msc mit administrativen Berechtigungen auf.
- Navigieren Sie dann im Gruppenrichtlinieneditor zu folgendem Zweig.
Der Zweig ist Computerkonfiguration->Administrative Vorlagen-> Windows Komponenten-> Remotedesktopdienste-> Remotedesktopsitzungs-Host-> Umgebung für Remote Sitzung. Dort ist ist die Richtlinie WDDM-Grafiktreiber für Remotedesktopverbindungen zu deaktivieren.
Sobald diese Richtlinie deaktiviert und die Übernahme ggf. mit gpudate /force erzwungen wurde, sollte das Remote Desktop-Fenster wieder etwas anzeigen.
Anmerkung: Dieser Bug wurde inzwischen offiziell durch Microsoft bestätigt und auf der Windows 10 V1903-Statusseite als bekanntes Problem aufgeführt (siehe Windows 10 V1903: 2 weitere Upgrade-Blocker bestätigt). Der obige Workaround hilft auch, falls RDP einen Kern der CPU auslastet (siehe Windows 10 V1903: RDP lastet CPU-Kern mit dwm.exe aus, VMs frieren ein). Der Bug wurde mit Update KB451294 behoben, was aber andere Probleme bringt (siehe Windows 10 V1903: Cortana erzeugt hohe CPU-Last sowie kaputte Suche durch August 2019-Updates).
Ähnliche Artikel:
Windows 10 Mai 2019 Update freigegeben
Windows 10 N: Media Feature Pack für Version 1903
Windows 10 V1903: Bekannte Probleme – Teil 1
Windows 10 V1903: Bekannte Probleme – Teil 2
Windows 10 V1903: 2 weitere Upgrade-Blocker bestätigt
Hallo,
bei meinem alten HP-Notebook trat das Problem auf (HP-Compaq 6710b) und ließ sich per GPO lösen. Mein Netbook AspireOne D270 war nicht betroffen.
Danke für den Hinweis.
Grüße
R.
Die AMD Radeon R7 350X ist Windows 10 v1903 kompatibel.
Sie bekommt den neuesten Radeon Treiber
-> https://www.amd.com/de/support/graphics/amd-radeon-r7-series/amd-radeon-r7-300-series/amd-radeon-r7-350
und ist damit v1903 ready
Hinweis für alle V1903 Updates, siehe hier
https://www.bleepingcomputer.com/news/microsoft/microsoft-removes-three-windows-10-1903-upgrade-blocks/
Die Dinger wohl zurückgezogen.
Nicht damit Missverständnisse entstehen: Microsoft hat drei Upgrade-Blocker auf die V1903 beseitigt.
Danke.
Die Deaktivierung der oben beschriebenen Gruppenrichtlinie „WDDM Grafiktreiber“ hat das Problem sofort behoben.
Vielen Dank.
Hatte das Problem auch auf 2 Maschinen. Wochenlange Suche in den einschlägigen Internetforen brachte keine zu verwertenden Informationen.
Tatsächlich scheint es nur ältere Maschinen mit bestimmten Grafiktreibern zu betreffen. Habe dann aber das Problem in vielen Versuchen noch differenzierter eingrenzen können: Die erste Verbindung, wenn an der Remote-Maschine kein Benutzer angemeldet ist, klappt immer, wenn auch etwas langsamer als gewohnt. Beende ich die Verbindung mit „trennen“ oder einfach nur Klick auf das Kreuz, geht danach gar nichts mehr. Auch eine lokale Anmeldung an dieser Maschine geht dann nicht. Nach längerer Zeit, habe manchmal bis 30 Minuten gewartet, geht die lokale Anmeldung wieder. Remote-Anmeldung dauert eine gefühlte Ewigkeit, aber der Desktop kommt dann wieder und man kann normal arbeiten. Beende ich aber die Verbindung mit „Abmelden“, kann ich mich danach sofort wieder neu verbinden, als käbe es das Problem gar nicht.
Heute fand ich den Hinweis mit dem WDDM-Eintrag in den Gruppenrichtlinien. Sofort ausprobiert, und siehe – das Problem ist weg. Kann wieder arbeiten, wie vorher. Mit einem Registry-Eintrag kommt man hier noch schneller ans Ziel, als mit den Gruppenrichtlinien, dort ist der betreffende EIntrag ziemlich tief versteckt.
REG ADD „HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services“ /v „fEnableWddmDriver“ /t REG_DWORD /d 0 /f
Hat das eventuell eine gemeinsame Ursache hiermit?
https://answers.microsoft.com/en-us/windows/forum/windows_10-performance/after-exiting-a-remote-desktop-session-cpu-load/e21e7da0-9a64-4a14-a671-b7cb1b61f66e?auth=1
Hallo, leider nein. Die CPU-Last geht nach der RDP-Sitzung noch immer hoch, auch mit o.g. Einstellung. :(
Vielen Dank für diese Beschreibung, jetzt funktionieren meine REMOTE-DESKTOP-Verbindungen wieder wie vor dem Update MS Win 10 Version 1903 ! Leider gehen da Stunden bei drauf, bis man das richtige findet, zum Glück gibt es aber immer einen, wie Günter Born, der anderen die Lösung näher bringt, das sollte eigentlich sofort von Microsoft behoben werden !!!
Ich habe die aktuellste Windows 10 Version 1903 inkl. Updates und keine alte Hardware, d.h. RDP-Verbindungen funktionieren problemlos. Was bei mir aber nicht funktioniert, ist, wenn ich eine RDP-Verbindung zu einer VM in VMware Workstation (neueste V15.1.0) aufbauen will, die auf einem anderen PC läuft. Die RDP-Verbindung wird noch initialisiert, danach friert die VM ein (freeze) und ist nicht mehr ansprechbar (es geht nur noch „power off“). In der VM läuft ebenfalls Windows 10 1903 mit aktuellem Stand.
Oben genannter Workaround hilft auch bei diesem Problem.
Zusatzinfo:
Meine VM’s sind eher schmalbrüstig und begnügen sich mit je 2 Kernen und je 2 oder 4GB RAM. Vor dem Windows Update lief alles problemlos.
Ich habe jetzt noch ein bisschen gepröbelt und folgendes herausgefunden:
Die zugeteilte RAM-Menge spielt keine Rolle (probiert mit 1GB und 8GB).
Sobald ich aber den VM’s mindestens 3 logische CPU-Kerne zuteile, läuft der RDP-Zugriff wieder problemlos. Wohlgemerkt ohne Patch: VM Runterfahren, wieder 2 Kerne einstellen, Hochfahren, RDP-Zugriff und Absturz..
Woran das jetzt wiederum liegt, das wissen wohl nur die Götter…
Auf jeden Fall hilft der Workaround.
Super Beitrag, hat geholfen.
Danke
Danke hat bei meinem alten HP Notebook geholfen
Super !!!l, das funktioniert vom feinsten mit der obigen Hilfestellung. Endlich seh ich wieder was ;-)))
Danke !!!
Vielen Dank, hatten zwar keinen Blackscreen, allerdings ist die Anmeldung über die RDP Verbindung nach dem Update immer eingefroren. Die Anmeldung auf dem Host (Windows 10 auf Virtualbox 6) hat dann lokal auch nicht mehr funktioniert weil auf dem Host der RDP-Prozess ausgelastet war, da half nur noch ein Hard-Reset. Mit dem Workaround läufts wieder absolut flüssig.
Ich habe die Lösung eigentlich schon Anfang letzter Woche woanders gelesen, aber nicht ganz korrekt befolgt. Nachdem es heute mit Einfrieren wieder los ging, habe ich es noch einmal getestet und es klappt einwandfrei. Bei uns hängt wirklich eine Menge davon ab, weil bei uns alle möglichen Tools über einen Proxy auf einer VM arbeiten.
Vielen Dank, HAtte das Problem mit Windows 10 1903 unter VMWARE. Jetzt geht wieder alles. Vielen Dank!!!
Danke, das funktioniert – endlich kann ich mittels NEOrouter auch wieder auf Windows VMs zugreifen.
Schön wäre, als Alternative Microsoft’s Remote Desktop App aus dem Store nutzen zu können, aber die funktioniert nicht mit dem VPN von außerhalb.
Also mit XDDM bekomme ich kein Vollbild. Heißt bei hohen Auflösungen schwarze Balken links und rechts… in Hyper-V ist eigentlich die maximale Auflösung (3840 x 2160) hinterlegt.
Weiß jemand woran das liegen kann?
War heute unerwartet damit konfrontiert. Aus einer Win 7-VM per RDP auf ein Win 10 (1903). In diesem Win 7 gibt es den XDDM-Eintrag in der Gruppenrichtlinie nicht. Könnte natürlich daran liegen, dass das Win 7 in einer Hyper-V VM unter Win 10 läuft.
Wenn die Win 7 VM hochgefahren ist, gehe ich normalerweise selber zuerst per RDP auf meine lokale Win 7 VM (das funktionierte noch) und von da dann weiter per RPD auf die fremde Maschine. Jedoch heute nicht, denn das RDP-Fenster blieb schwarz.
Und ich bin mir sicher, dass es trotz Build 1903 kürzlich noch funktioniert hat, was bedeuten würde, dass neuere Windows Updates da noch mal wieder was dran gedreht haben.
Mir hat letztlich geholfen, statt per RDP auf die VM, im Hyper-V-Manager des Host über die Funktion ‚Verbinden‘ zur VM zu kommen. Da funktionierte dann der nächste Schritt mit RDP auf die fremde Maschine wieder. Seltsam.
Wenn es also mit den Grafiktreibern bzw. dem Treibermodell zu tun hat, wieso hakt es dann auch mit dem Treiber / Treibermodell in einer Hyper-V VM? Die kann doch gar nichts von der echten Hardware in dem Hyper-V Host wissen.
Super wenn das Problem so behoben werden kann. Jetzt habe ich nur das Problem, dass ich rund 30 VDIs mit dem Problem habe. Habe probiert, die Einstellungen via Domain GPO zu machen. Leider fehlt genau der Eintrag „WDDM verwenden“ via Domain? Hat jemand eine Ahnung, wie ich das sonst zentral konfigurieren kann?
Danke und Gruss!
Habs hinbekommen via Verteilung eines Registry-Keys. Habe dazu die beiden folgenden Anleitungen kombiniert:
https://theitbros.com/add-modify-and-delete-registry-keys-using-group-policy/ und https://www.windowspage.de/tipps/022367.html
Bei mir ist auch ein Server 2012 R2 davon betroffen.
Kann das jemand bestätigen? Die lok. GPO Einstellungen zu WDDM habe ich da nicht gefunden.
Super. Genau das war die Lösung. Vielen Dank!!!
Das Fehlerbild schwarzer Bildschirm im RDP-Client haben wir in leichter Variation.
Die Testumgebung besteht aus W10 v.1909 als VMware Host und in der VM. Nach dem Verbinden mit RDP erscheint kurz der Desktop des Zielsystems, der dann aber einfriert und nach ca. 10 Sekunden folgende Fehlermeldung bringt:
„Die Sitzung wurde aufgrund eines Protokollfehlers getrennt. Versuchen Sie, die Verbindung mit dem Remotecomputer wiederherzustellen.“
Nach Bestätigung mit „OK“ wird die Verbindung zum Zielsystem wahrscheinlich nicht sauber beendet und bei nachfolgenden Verbindungsversuchen bekommt man regelmäßig einen schwarzen Bildschirm im RDP-Client, bis man sich über die VM-Konsole an- und abmeldet.
Das Fehlerbild mit dem schwarzen Bildschirm führte mich nun zu der hier beschrieben Lösung (über die GPO den WDDM deaktivieren). Offensichtlich hat man bei MS mit v.1909 die Fehlerausgabe des RDP-Clients im Falle von Problemen mit dem WDDM-Grafiktreiber „verbessert“. Die beschriebene Lösung
-Deaktivieren des WDDM-Treibers per GPO- hat das Problem gelöst!
Vielen Dank!
RIESENGROSSES Dankeschön! Hat mir unendlich viel Zeit bei der Fehlerdiagnose erspart!
Diese Lösung funktionierte bei mir auch nach einer RDP Fehlermeldung nach WIN10-Update auf Version 2004 (Frühjahr 2020)
Ich habe das Problem auf einer frischen Win 10 2004 Installation und neuer Hardware (Dell Precision 7550 Laptop). Keiner der Tipps hat geholfen. Sämtliche Treiber sind aktuell.
Ich hatte unter 20H2 das gleiche Problem, trotz aktueller NVIDIA und Intel Treiber.
RDP Session disconnected => kein Reconnect mehr möglich. Nur ein Neustart des PCs hat geholfen; danach war eine ein- oder zweimalige Verbindung möglich.
Ab und an auch einer längerer schwarzer Anmeldebildschirm.
Folgende Fehler waren in meinem Eventlog:
Event ID 10110 DriverFrameworks-UserMode
A problem has occurred with one or more user-mode drivers and the hosting process has been terminated. This may temporarily interrupt your ability to access the devices.
Event ID 10111 DriverFrameworks-UserMode
The device Microsoft Remote Display Adapter (location (unknown)) is offline due to a user-mode driver crash. Windows will attempt to restart the device 4 more times. Please contact the device manufacturer for more information about this problem.
hi, und konntest du es lösen?
habe einen 2016 Server als Host mit einem Win 10 20H2 mit schwarzem Bild… GPO bringt nix…