Windows Server 2019/2022: Terminal Server/RDS und die einfrierende Windows Start-Schaltfläche oder Taskleiste

Windows[English]Ich greife mal ein Thema auf, welches mir in Fragmenten hier im Blog als Kommentare sowie auf Twitter unter die Augen gekommen ist. Es liegen mir verschiedene Berichte vor, die über Probleme mit einer einfrierenden Windows Taskleiste oder Start-Schaltfläche auf Windows Terminal Server berichten. Irgend einen Bock hat Microsoft da mit den letzten Updates hinterlassen.


Anzeige

Ein Benutzerhinweis

Franz hat mich auf Twitter kontaktiert und beschreibt dort seine Erfahrungen mit der hängenden Windows Taskleiste folgendermaßen:

Haben ganz komischen Effekt auf Terminal Server (serv 2022). Wenn man in Edge ist und dann auf Startleiste klickt entsteht eine Pause von ca. 1-2 Sekunden. Vermutlich seit Update auf 20348.1487 Irgendeine Idee?

Terminal Server 2022: Start is freezing in Windows

Franz hat den Effekt, dass die Start-Schaltfläche unter Windows Terminal Server, gehostet unter Windows Server 2022, bei Verwendung des Edge-Browsers für 1-2 Sekunden einfriert. Er vermutet das Update auf die Build 20348.1487 (siehe Patchday: Windows 11/Server 2022-Updates (10. Januar 2023)). Bezüglich der Frage nach einer Idee, fiel mir folgender Kommentar ein.

Ein weiterer Benutzerkommentar

Im Blog-Beitrag Windows 10/11: Microsoft bestätigt Taskbar-Probleme mit Barco ClickShare-App Kalenderintegration hatte ich über Probleme mit einer nicht reagierenden Taskleiste berichtet – wobei da aber ein leicht anderes Fehlerbild auftritt. Aber zu diesem Blog-Beitrag hatte sich Michael mit folgendem Kommentar gemeldet:


Anzeige

Seit dem letzten Windows Update friert die Taskleiste auf einem Terminal Server für ca. 5 bis 60 sek ein. Auslastung, Speicher usw ist alles im dunkelgrünen Bereich. Wenn es auftritt, hat auch kein Prozess eine hohe Auslastung.

Barco ClickShare ist nicht vorhanden. Gibt bereits im Netz ein paar Meldungen zu dem Thema. (incl. Server neu starten und geht dann für ein paar Tage).

Das ganze ist User unabhängig, auch Administrator ist betroffen. Zusammenhänge konnte ich in Verbindung mit Edge erkennen.

Das deckt sich mit dem, was Franz auf Twitter beschrieben hatte. Michael gibt an, dass ein Neustart des Servers das Problem für einige Tage behebt. Franz hat sich dann ergänzend mit folgendem Kommentar gemeldet.

Identisches Problem

Allerdings sind die Pausen in der Taskleiste bis zu 20 Sekunden. Geöffnete Programme können weiter bedient werden. Mit Zeitverzögerung kommen dann die Klicks in der Taskleiste.

Bei Administrator.de ist auch ein Bericht darüber [GB: Ich vermutet, es ist der Beitrag Terminalserver 2016 Start- bzw. Taskleiste friert sporadisch ein vom 2.11.2022 gemeint]

Auch bei answers.Microsoft.com (bape hoodie8) mit Hinweis auf Taptip bzw TapTip32.exe. Aber Taptip Kill brachte keine Verbesserung

Bei den erwähnten Programmen Taptip.exe bzw. TapTip32.exe scheint es sich um den TabletInput-Service zu handeln.

Ein Beitrag im Microsoft Answers-Forum

Der von Franz erwähnte Microsoft-Answers-Forenbeitrag Windows 2022 Server RDS – TaskBar regularly lags, is slow, or freezes ist vom 16. Januar 2023 und enthält folgende Beschreibung:

Windows 2022 Server RDS – TaskBar regularly lags, is slow, or freezes

Taskbars on Windows 2022 Remote Desktop servers freeze for RDP users

When attempting to click on the taskbar, for example to switch between apps or right-click for task management, we are noticing that there is a delay of between 30 and 45 seconds (varies) in all sessions, including admin and local.

On Windows Server 2022 RDS, there are problems with the task bar and sporadic task bar freezing.

If you click back into your application after the taskbar has lost focus, it will take a little while for the taskbar to respond when you try to click on it again.

Both of our 2022 RDS servers are experiencing this, and a clean boot does not fix the problem. They are also properly patched.

Also auch dort findet sich dieses Fehlerbild, dass auf Windows Server 2022 die Taskleiste für RDP-Nutzer für eine gewisse Zeit einfriert, wenn diese angeklickt wird. Dort findet sich ein Verweis auf den Blog-Beitrag Windows Server 2022 Freezing/Very Laggy Taskbar von Dezember 2022. Dort werden die erwähnten Programme Taptip.exe bzw. TapTip32.exe durch Umbenennen deaktiviert. Scheint aber bei Franz keine Verbesserung.

Weitere Fundstellen

In der Techcommunity von Microsoft gibt es den Benutzereintrag Windows 2022 Server RDS – TaskBar Laggy/Slow/Freeze frequently vom 11. Januar 2023 mit einer ähnlichen Beschreibung des Fehlerbilds.

Windows 2022 Server RDS – TaskBar Laggy/Slow/Freeze frequently

Windows 2022 Remote desktop servers taskbar freezing in RDP users

We are finding the task bar in all sessions (including admin/local) suffer from a delay of 30-45 seconds (varies) when trying to click on the taskbar i.e. to change applications or right click for task manager.issues with the task bar/random task bar freezing on Windows Server 2022 RDS
Once the taskbar has focus its responsive as usual, but once it loses focus i.e. you click back into your application, when you try to click on the task bar its delayed to respond again.

This is happening on both our 2022 RDS servers – clean boot doesn't resolve the issue, they are fully patched to date.

Troubleshotting steps:

-Restart the "Explorer" process
-recreate user profile in RDP
-update the latest windows patch
-Run sfc/scannow
-Disable programs on the Startup tab

If you know anyone please give a solution/feedback.

Zu diesem Post gibt es im Februar 2023 noch keine Antwort. Auf spiceworks.com findet sich ebenfalls der Community-Beitrag Server 2022 RDS Taskbar and Start menu Lagging and Freezing vom 16. Januar 2023.

Server 2022 RDS Taskbar and Start menu Lagging and Freezing

I have a brand new Server 2022 RDS server and have around 10 users on it.  We have has multiple reports that the taskbar and start meny lag or freeze up.  I was able to easily replicate this issue but not sure how to fix.  I've googled the issue and this is what I've done so far:

1.  Created a DWORD key at

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy

and set it to 1

2.  Disabled the firewall altogether

3.  Temporarily disabled AV (Sentinel One)

4.  Set a task to reboot the server every morning at 3am.

Any help on this issue would be appreciated.  While it's not a showstopper, it is an annoyance.

Der reddit.com-Beitrag hier ist dagegen bereits 8 Monate älter und könnte andere Ursachen haben. Es scheint verschiedene Ursachen zu geben. Jemand von euch, der das Problem ebenfalls hat und eine Ursache sowie eine Lösung kennt?

Rückmeldungen auf Facebook

Ich hatte den Link zu diesem Beitrag in diversen deutschsprachigen Facebook-Gruppen gepostet. Dort habe ich ebenfalls Rückmeldungen erhalten. Joachim B. schrieb in einem Kommentar:

Ja! Hab mich schon gewundert warum das niemand sonst passiert. Windows Server vNext hat dasselbe Problem.

Von Tom B. gab es dann den nachfolgenden Kommentar (der Hinweis auf 2019 ist dahin gehend zu verstehen, dass ich in meinem Post Windows Server 2022 explizit als Betroffen erwähnt hatte):

Auf TCP umgestellt im RDP File, aber das tritt auch bei 2019 auf.

Bezüglich der Umstellung auf TCP geht mir der Beitrag Windows 11 22H1: RDP-Probleme per Preview-Update gefixt, wie ist sonst der Status? im Kopf herum. Das Preview-Update steht ja nur für Windows 11 22H1 zur Verfügung. Ich bin mir aber unsicher, ob hier nicht ein anderer Fehler vorliegt.

Ursachen und Workarounds

Ergänzung: Interessant fand ich noch die Erklärung von Rene S. in der Server-Gruppe auf FB, als Reaktion zu meinem Post. Dort schimmert eine mögliche Ursache samt Workaround für dieses Problem durch:

Hatte dies mal bei einem Kunden:

HKLM\SYSTEM\Software\Microsoft\TIP\TestResults

läuft voll. Sobald man die Einträge löscht läuft wieder alles.

Als ich dann nach diesem Schlüssel gesucht habe, gab es viele Treffer, die bis ins Jahr 2021 zurückreichen. Bei Microsoft gibt es diesen Post mit folgendem Inhalt:

Server 2022 and Teams Bloats HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\TIP\TestResults\

Hi, has anyone else deployed MS Teams on Server 2022 and noticed bloating of the registry key:

HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\TIP\TestResults\

We need to clear this daily to prevent slow downs. From what I can see, it seems to be only written to by MS Teams.

Microsoft Teams wird dort als Verursacher eines Problems beschrieben, dass den genannten Schlüssel TestResults voll schreibt. MS Teams als Verursacher wird aber in Folgekommentaren negiert. Jemand hat folgenden Screenshot mit dem voll laufenden Schlüssel gepostet.

HKLM\SYSTEM\Software\Microsoft\TIP\TestResults

Ein Nutzer hat im Kommentar-Thread bei Microsoft noch folgende Script-Anweisungen gepostet, um den gefüllten Schlüssel TestResults zu löschen.

Remove-Item -Path "HKLM:\SYSTEM\Software\Microsoft\TIP\TestResults\27641008" -Recurse
Remove-Item -Path "HKLM:\SYSTEM\Software\Microsoft\TIP\TestResults\27641370" -Recurse

Es gab zudem den Hinweis eines Nutzers:

Danke, ich habe gerade die Berechtigung so geändert, dass das System nicht unter TestResults schreiben kann ;)
Aber es funktioniert wie geschmiert – keine Probleme mehr, seit die Schlüssel weg sind.

In den Antworten in obigem Tweet gibt es auch noch den Hinweis eines Nutzers, der UDP für Remote Desktop Protocol-Sitzungen per Gruppenrichtlinie deaktiviert hat und schreibt, dass es geholfen habe (also das, was ein Facebook-Nutzer oben ebenfalls angerissen hat).

Franz, der weiter oben bereits auf den Fehler hinwies, hat nachfolgend noch den Link auf die Diskussion Server 2022 Taskleiste friert ein bei administrator.de als Kommentar gepostet. Auch dort taucht der Hinweis auf obigen Schlüssel TestResults auf und ein Benutzer mit dem Alias laster kommentierte:

habe den Inhalt von HKLM\SYSTEM\Software\Microsoft\TIP\TestResults gelöscht.

Sobald ein Edge gestartet wird, werden wieder neue Unterordner in dem Reg-Pfad erstellt.

Kann man das ausschalten, bzw wozu ist das gut?

Und ergänzt dann:

Verantwortlich für die Einträge sind die Programme

C:\Program Files\Common Files\microsoft shared\ink\TabTip.exe
C:\Program Files (x86)\Common Files\microsoft shared\ink\TabTip32.exe

Den Dienst-Start kann man mit dem Reg-Key

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TabletInputService\Start=4

verhindern.

Der Tipp mit dem Verhindern des Dienststarts scheint aber nicht zu klappen, wie ein Nutzer schreibt. Auch das Abschießen der Programme des Tablet Input Service hilft wohl nicht. Am Ende des Tages hilft nur, den Eintrag des Schlüssels TestResults zu leeren. Es wird ein Januar 2023 Update als Grund vermutet. Ich habe das Thema auch im englischen Blog aufgegriffen und dann hier und hier an Microsoft gemeldet.

Nachtrag: Meine Meldung des obigen Fehlers auf Twitter an MicrosoftSupport mit der Bitte, den Link zu diesem Artikel an deren Support-Ingenieure weiterzuleiten, wurde wie folgt beantwortet:

Hi! We got your tweet, and we hope you don't mind us sending you a direct message. Let's continue our conversation here. We encourage you to send your feedback on this issue using the Feedback Hub app (msft.it/60165Pf3r) to send your feedback directly to our engineers. Please include information like screenshots, device details, and an explanation of how your issue occurred whenever possible. Your feedback is very important as it helps us improve Windows performance. Thank you in advance! -Rom

Meine Antwort war kurz und bündig: I'm not going to fire up some silly Windows 10/11 to to add something into a feedback hub. Take it (my link) or leave it … – Ich werde nicht irgendein albernes Windows 10/11 hochfahren, um etwas in einen Feedback-Hub einzufügen. Nimm ihn (meinen Link) oder lass es bleiben …

Ähnliche Artikel:
Windows 10: Taskleiste und Office-Anwendungen streiken (18. Jan. 2023)
Neues zu Windows 10/11 Taskleisten- und Intune-Problemen (Barco ClickShare, 18. Jan. 2023)
Windows 10/11: Microsoft bestätigt Taskbar-Probleme mit Barco ClickShare-App Kalenderintegration


Anzeige

Dieser Beitrag wurde unter Störung, Windows, Windows Server abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

20 Antworten zu Windows Server 2019/2022: Terminal Server/RDS und die einfrierende Windows Start-Schaltfläche oder Taskleiste

  1. Stefan sagt:

    Ich hatte früher mal Probleme auf einem Terminalserver mit ClassicShell beobachtet, seither dort nie mehr ClassicShell bzw. bzw. OpenShell eingesetzt.

  2. js sagt:

    Also ich weiss nicht ob das dazu passt oder direkt hilft, aber ich würde alles daran setzen zu vermeiden, dass MS den edge.exe weiter in Desktopelemente verstrickt mit denen der nichts zu tun haben sollte.
    Zu allererst gehört via GPO "News and Interests" und "Search Highlights" weggeprügelt – neulich hat das noch geholfen, dass edge.exe dann nicht unaufgefordert mitläuft.
    Dann muss man sich vermutlich auf die Lauer legen, was für Zeugs denn als nächstes Monat für Monat und Edgeupdate für Edgeupdate dazu kommt.
    Der heiße Scheiß wird ja bald der Edge-Adobe-PDF-Betrachter und ich gehe in Deckung, was für Brücken die davon aus (hoffentlich nicht) in das Drucksystem bauen.
    Weil MS den edge.exe nach Belieben an WU vorbei mit einem alternativen eigenen Updater in die Systeme hinein kompromittiert, sollte man bei TS die entsprechenden ScheduledTasks monitoren und das besser selber timen, damit man parallel dazu auch die Edge-GPOs (die sie ja dumpferweise nicht mit befördern sondern die man sich selber beschaffen muss) auf Veränderungen untersuchen kann.

    • 1ST1 sagt:

      Bei uns machen die Terminalserver garkeine automatischen Anwendungs-Software-Updates. Windows-Patchday-Updates laufen gestaffelt automatisch ab, erste Nacht ein paar Test-TS, dann die nächste Nacht ca. 30% der gesamten Farm, dann der Rest. Anwendungssoftware wird per Deploymentsoftware aktualisiert, nachdem die Software 2 Tage auf denm Desktops lief. Und das ist auch bei Browsern so, weil unsere Terminalservernutzer einige kritische Webapplikationen nutzen, ohne die der Laden schnell still stehen würde. Da darf kein Browserupdate diese Anwendungen bricken.

      Automatische Software-Updates sind auch insbesondere in einer Citrix-Umgebung, bei der die Terminalserver dynamisch per Provisioning-Service aus einem Masterimage generiert werden, eine dumme Idee. Denn jedes automatische Softwareupdate vergrößert den Write-Cache der einzelnen TS-VMs, das kostet Platz auf dem Storage und es kostet Performance. Sollte man unbedingt vermeiden. Updates macht man manuell oder per Deployment auf einem per Versionierung erstellten neuen Master-Image. So oft wie momentan Edge und Chrome aktualisiert werden, darf man diesen Schritt momentan fast täglich machen.

      • Daniel sagt:

        Hm, macht das auf Dauer noch Spaß? Könnte mir auch was Schöneres vorstellen, wenn ich zur Arbeit gehe – auch wenn ich Dich inhaltlich wie technisch verstehe. Ob ich das noch 35J so bis zur Rente so machen will – glaube nicht. Kann man nur hoffen, dass sich da was in 203X grundlegend ändert.

        • 1ST1 sagt:

          Diese Standardsachen gehen ja weitestgehend automatisch, da ist nichts dabei. Die Herausforderungen sind wo anders. Ein Bäcker backt jede Nacht auch die selben Brote.

  3. 1ST1 sagt:

    "(incl. Server neu starten und geht dann für ein paar Tage)"

    Ich kenne das aus verschiedenen Terminalserver-Umgebungen so, dass die TS sowieso jede Nacht per Aufgabenplanung automatisch neu gestartet werden. Der Reboot sollte nur so eingestellt werden, dass die WSUS-Update-Checks erst nach dem automatischen Reboot statt findet.

    • Joachim sagt:

      Wir starten auch alle Session Hosts einer virtualisierten 2019 Farm täglich in der Nacht neu.
      Seitdem haben wir viele Probleme nicht mehr, vor allem mit RAM, Leistungsabfall, Anmeldeproblemen, temporären Profilen usw.

      Außerdem ist Office 32bit installiert (RAM-Probleme mit wildgewordenen Exceldateien unter 64bit) und der Outlook Logging Ordner wird bei jeder Anmeldung gelöscht und als Datei neu angelegt, damit der Ordner nicht mehr erstellt werden kann: https://learn.microsoft.com/en-us/answers/questions/873246/etl-files-in-c-usersuserappdatalocaltempoutlook-lo

      Warum MS solche Baustellen nicht selbst behebt ist eine andere Sache. Aber mit relativ wenig Aufwand haben wir so zufriedene User und zufriedenen Support, ohne in Hardware oder Lizenzen investieren zu müssen. Was will man mehr in der IT ;)?

      (PS: offen ist noch Firefox, der leider für eine wichtige Anwendung benötigt wird. Der schreibt bei Updates gerne neue Profile, was schon zu vollen Profldisken geführt hat, mit >18GB an Profilkopien. Mozilla ist der Bug seit mehreren Jahren bekannt!).

  4. Paul sagt:

    Manche Leute mögen immer wieder das Gleiche zu tun, andere nicht.
    Jedem das Seine.

    Vermutlich auch ein Grund warum es immer noch MS Produkte in missionkritischen Bereichen gibt…
    Wenn es nicht funktioniert kann man immer wieder mit seinem Wissen die Firma retten. Erinnert mich aber leider auch an den Krankenpfleger mit der Kalium-Spritze…

    Ich verstehe einfach nicht warum man sich so in Abhängigkeit begeben kann.

    • 1ST1 sagt:

      "warum es immer noch MS Produkte in missionkritischen Bereichen gibt"

      Ich muss dir da deine Linux-Träumereien mal wegnehmen, aufwachen, ohne Windows-Systeme würde unsere Wirtschaft und Gesellschaft nicht funktionieren, genauso wenig, wie man auf Linux-Systeme verzichten könnte.

  5. Thomas sagt:

    Ich habe auf meinem Laptop Windows 10 22H2 installiert und immer mal wieder das Problem, dass das Startmenü nicht mehr funktioniert. Habe jetzt den TabletInputService deaktiviert. Brauch ich sowieso nicht, weil das Laptop überhaupt eine solche Funktionen nicht bietet. Bin gespannt wie es sich entwickelt. Aber der Tipp hier war ein fach zu verlockend, um es nicht zu probieren.

  6. techee sagt:

    Da serviert man denen schon das aufbereitete Problem + Analyse auf dem Silbertablett und dann wolllen die noch, dass man in irgendeine beknackte Feedback App geht und dort für die erneut das Problem meldet.
    Von daher finde ich die kurze Antwort am Ende des Beitrags super :-D

  7. zweiundvierzig sagt:

    I'm not going to fire up some silly Windows 10/11 to to add something into a feedback hub. Take it (my link) or leave it …

    ich musste herzlich lachen. Vielen Dank für die Aufheiterung an einem grauem Montag

  8. Franz sagt:

    Als Update:
    4 Tage nach dem Neustart fangen die Taskbar Aussetzer wieder an. Da ich die Tip Registry Einträge nicht gelöscht hatte und nach dem Neustart der Effekt weg war, wäre ich mir nicht sicher ob da wirklich ein Zusammenhang ist.

    Allerdings ist in der Umgebung auch teams im Einsatz.

  9. Max sagt:

    Hi,
    vielen Dank, ich kenne diese Probleme auch. Ich habe die Einträge eben gelöscht und warte nun auf Rückmeldung.
    Ich habe nur ein kleines Problem…ich habe wie in deinem genannten Kommentar dem SYSTEM am TestResults-Eintrag die Schreibrechte weggenommen und jetzt kann ich auf die Einträge nicht mehr zugreifen :D Hab dem SYSTEM die Rechte wieder gegeben und testweise auch "Jeder" Vollzugriff gegeben, keine Chance. Habe sogar eine Powershell mit SYSTEM-Rechten versucht, auch damit kann ich die Dinger nicht löschen. Problem ist, ich weiß jetzt nicht, ob dort noch fleißig reingeschrieben wird oder ob das nun auch für z.B. Edge usw nicht mehr möglich ist (was ja nicht das schlechteste wäre). Hm. Jemand eine Idee?^^

    Danke

    • Max sagt:

      Problem ist inzwischen gelöst, aber ich habe mir noch angeschaut, wer oder was diese Registry-Werte erstellt. Aber so ganz klar ist mir die Sache nicht. Laut ProcMon greift neben der TabTip.exe (die bei mir inzwischen TabTip.exe.org heißt, also unbenannt ist eingetlich gar nicht mehr darauf zugreifen "dürfte") auch die Explorer.exe immer wieder darauf zu und erstellt neue Registry-Werte.

      Bei mir läuft jetzt erstmal ein Billig-Script, das alle 10 Sekunden die Werte löscht *schulterzuck*

      :loeschen
      timeout 10
      reg delete "HKLM\SYSTEM\Software\Microsoft\TIP\TestResults\27641008" /f
      reg delete "HKLM\SYSTEM\Software\Microsoft\TIP\TestResults\27641370" /f
      goto loeschen

      Mal schauen :)

  10. Patrick sagt:

    Hallo in die Runde,
    wir haben dies Problem anscheinend auch, Server 2022 mit Teams.
    Gibt es dort schon etwas neues?
    Lasst ihr noch Scripts laufen?

    Grüße Patrick

  11. Burkhard sagt:

    Wir haben das selbige Problem, neben dem üblichen Office Kram auch WebEx, Zoom und Teams auf dem WTS.

    Ich hatte Firefox (wird für UnternehmensApp genutzt) alternativ TobitDavid Client in Verdacht (wg. Chromium Engine), es war aber der Explorerneustart der das Benutzerprofil wieder nutzbar machte …

    Ich benutze jetzt erst mal dankend auch das Script ;-=
    Die Liste der Einträge in TestResults war unglaublich lang

    Zusätzlich werde ich wohl auch einen Neustart (normalerweise nur alle 2 Wochen geplant) einplanen, blöde dabei ist das Unternehmen arbeitet fast 24X7.

    Bei mir ist aber zusätzlich noch ein Schlüsselname HKEY_LOCAL_MACHINE\SYSTEM\Software\Microsoft\TIP\TestResults\27281911
    unter dem sich ebenso eine sehr sehr lange Liste von (mEA nutzlosen) Einträgen befindet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.

Du findest den Blog gut, hast aber Werbung geblockt? Du kannst diesen Blog auch durch eine Spende unterstützen.