Nutzer von Windows 11 24H2 kämpfen seit dem Januar 2025-Patchday mit RDP-Problemen. Verbindungen brechen ab oder lassen sich nicht herstellen. Ich hatte das Thema im Blog und Microsoft hat das Problem bestätigt. Nun gibt es eine Lesermeldung, dass die RDP-Probleme seit Ende Juni 2025 behoben seien. Lässt sich das bestätigen?
Das Windows RDP-Problem
Benutzer beklagten sich seit Monaten, dass der Zugriff auf Windows 11 24H2-Clients mittels RDP unmöglich sei. Ich hatte im Blog-Beitrag Weiterhin RDP-Probleme unter Windows 11 (Feb. 2025)? das Thema RDP-Probleme in Verbindung mit Windows 11 angesprochen und das Thema auch nochmals im März 2025 im Beitrag Windows 11: März 2025-Updates verursachen Probleme mit RDP-Verbindungen aufgegriffen.
Zum 27. März 2025 hatte Microsoft in den Known Issues des Windows 11 24H2 Health Dashboard den Support-Beitrag Remote Desktop might disconnect with January 2025 preview updates and later eingestellt (siehe auch meinen Blog-Beitrag Windows RDP-Probleme durch Januar 2025-Update von Microsoft bestätigt).
Microsoft schreibt, dass es nach der Installation des Windows-Preview-Updates vom Januar 2025 ((KB5050094) und späterer Updates bei Benutzern von Windows 11 24H2 zu Verbindungsabbrüchen bei RDP-Sitzungen (Remote Desktop Protocol), einschließlich Remotedesktopdiensten (RDS), kommen kann. Microsoft schreibt zudem, dass man nach der Veröffentlichung des Windows-Sicherheitsupdates vom März 2025 (KB5053598) eine deutliche Zunahme der Berichte über dieses Problem beobachtet habe.
Benutzer bemerken laut Microsoft möglicherweise, dass ihre RDP-Sitzungen unerwartet nach 65 Sekunden getrennt werden, wenn sie UDP-basierte Verbindungen von Windows 11, Version 24H2-Geräten zu RDS-Bereitstellungen mit Windows Server 2016 oder früher herstellen. Infolge dieses Problems kann es bei Benutzern zu häufigen Unterbrechungen ihrer Remotedesktop- und RDS-Sitzungen kommen.
Hat das Juni 2025-Update was gefixt?
Blog-Leser Ulrich W. hat mich zum 25. Juni 2025 per Mail kontaktiert, weil er von diesem Problem ebenfalls betroffen war. Er schrieb mir dazu, dass er nebst einigen anderen Nutzern von dem Problem, was ich oben beschrieben habe, bei den von ihm benutzten WTS-System bei RDP-Zugriffen betroffen war und referenzierte in seiner Mail die Blog-Beiträge am Artikelende. Das Kürzel steht wohl für Windows Terminal Server (WTS).
Alle Versuche, das Problem mit Registry- oder GPO-Änderungen wieder zum Laufen zu bekommen, seien recht erfolglos gewesen, merkte der Leser an. Dann gab Ulrich an, dass bei ihm "seit einigen Tagen der WTS-Zugriff wieder funktioniert". Die RDP-Zugriffe seien "jetzt von mehreren Windows 11-Benutzern getestet und wieder als OK zurückgemeldet worden". Er vermutet, dass dies auf eines der letzten Windows 11 Updates zurückführen sei. Er wollte es selbst im Anschluss evaluieren, aber ich habe bisher keine Rückmeldung diesbezüglich.
Im April 2025 gab es zwar angeblich einen Fix der Remote Desktop-Freezes (siehe Windows 11 24H2/Server 2025: Microsoft fixt Remote Desktop-Freezes durch Feb. 2025 Update). Aber beim Leser scheinen die RDP-Probleme weiter bestanden zu haben. Daher die Frage an die Leserschaft: Lässt sich bestätigen, dass es nach April weiter RDP-Verbindungsprobleme in Windows 11 24H2 gab und dass diese seit Ende Juni 2025 behoben sind?
Ähnliche Artikel:
Weiterhin RDP-Probleme unter Windows 11 (Feb. 2025)?
Windows 11: März 2025-Updates verursachen Probleme mit RDP-Verbindung
Windows RDP-Probleme durch Januar 2025-Update von Microsoft bestätigt
Windows 11 24H2/Server 2025: Microsoft fixt Remote Desktop-Freezes durch Feb. 2025 Update



MVP: 2013 – 2016




Habe die letzten 6 Monate keine RDP-Probleme mit 24H2 bemerkt. Es scheint wohl kein allgemeines Problem zu sein, sondern irgendwas spezielles.
Windows Update
Es sind Updates verfügbar.
Letzte Überprüfung: Heute, 22:25
Security Intelligence-Update für Microsoft Defender Antivirus — KB2267602 (Version
1.431.480.0) — Aktueller Kanal (Allgemein)
2025-07 Kumulatives Update für Windows 11 Version 24H2 für x64-basierte
Systeme (KB5062553)
2025-07 .NET 8.0.18 Update for x64 Client (KB5063326)
bei mir konnte ich die Abbrüche vollständg lösen, indem ich die Drucker unter "lokale Ressourcen" nicht mehr mit durchschleife.
Ich verbinde von Win11 24H2 zu Win11 24H2
Ich habe diese Probleme seit Monaten sporadisch. Nicht dramatisch, aber es kommt noch vor, auch nach den Juli Updates.
Bei mir funktioniert mit 24H2 wenigstens endlich die Audiowiedergabe ohne Aussetzer. Zuvor kam es bei anderen Aktivitäten wie Surfen, Datei-Öffnen u.ä. immer wieder zu lästigen Aussetzern (immer 4x hintereinader im 5sek-Abstand), egal in welchem Energiemodus, auch wenn alle 12 Kerne entparkt.
Jetzt haben sich die Interruptzeiten geviertelt und die Treiberlatenzen (insb vom Wdf01000, ntoskrnl und dxgkrnl) ebenfalls und damit sind auch die Aussetzer weg. Werte gemessen mit LatrencyMonitor.
Selbst mit weit schwachbrüstigeren Computern hatte ich solche Probleme nie unter W2000, W7, W8/8.1 und W10.
Hier mal ein bisschen tiefer:
Seit Win 11 (vorher Win 10) erfolgt ein Zwangswechsel XDDM/WDDM.
d.h. vorherige Deaktivierungen sind jetzt so Legacy, dass sie deaktiviert wurden.
Mit anderen Worten: Windows versucht den neuen Treiber zu laden.
Hat man eine strenge GPO die das Installieren von Gerätetreibern blockiert, dann kann man sich nicht verbinden, weil Windows just in dem Verbindungsmoment diesen Gerätetreiber installieren möchte (aber da non-Admin + non-PNP) nicht darf.
d.h. man benötigt eine Ausnahme für diese Art von Gerätetreiber über die GUID.
Weiterhin gilt der alte Tipp UDP zu deaktivieren. Ob es jetzt mit UDP besser klappt habe ich noch nicht getestet.
Alles in allem klappt es soweit.
JEDOCH:
Ist man längere Zeit nicht am Remotecomputer und verbindet z.B. per RDP auf Win11Pro, dann wird evtl. der Bildschirm Remote schwarz und nichts geht mehr.
Lokales Login mit gleichem User führt dann zu "Bitte warten.."
Nichts geht mehr…
Loggt man sich im LAN (nicht Homeoffice) Remote ein, dann kann man mit dem gleichen Nutzer die Sitzung reaktivieren. Es klappt auch soweit, man trennt die Verbindung und dann kann auch der Remote Homeoffice User wieder reingehen…
Fragt nicht wieso.. die Lösung suche ich selbst..