PVS target device reagiert nicht mehr (full cache)

Table of contents

Setup

Ein paar Fakten zur Umgebung:

• Terminal servers mit Windows Server 2016
• Citrix (Delivery Controller, VDA, PVS) in der Version 1912CU1
• PVS caching mode: Cache on device RAM with overflow on hard disk
• 10 von 800 VDAs waren täglich davon betroffen

Das Problem

Das Problem im Detail: Die VDAs starten täglich neu und direkt danach funktioniert alles problemlos. Nach einer gewissen Zeit (manchmal nach einer Stunde, manchmal nach 10 Stunden und manchmal nie) reagieren die VDAs nicht mehr.

Es “reagiert nicht mehr” bedeutet, dass die Sessions auf den Server einfach hängen. Manchmal hing die komplette Maschinen. Manchmal konnte ich mich aber auch anmelden auf der Maschine, aber es war alles sehr langsam. Meistens war es sich nicht möglich anzumelden (egal ob lokaler Benutzer oder Domänenbenutzer). Der Citrix Director zeigte keine aktuellen Daten mehr an über die Maschine.

Erster Hinweis

Nach ein paar Tagen konnte ich mich endlich auf eine Maschine anmelden. Ich öffnete den Explorer und sah mir die Disken an. Nach ca. 3 Stunden warten, sah ich endlich den Explorer und ich sah, dass die D:\ Disk (fast gänzlich) voll war. Das größte File war die vdiskdif.vhdx.

Troubleshooting

Ab diesen Zeitpunkt wusste ich, dass etwas den vDisk Cache vollfüllt, aber ich wusste nicht was genau. In der Theorie wäre es praktisch zu sehen was genau versucht auf C:\ zu schreiben um zu sehen weswegen der vDisk Cache voll wird. Ich kenne nicht wirklich ein (ressourcenschonendes) Tool um das durchzuführen - Process Monitor kann das zwar, aber die ganze Zeit laufen zu lassen ist keine Option (das würde das System sogar noch vorher zum abstürzen bringen). Und auch wenn ich das machen wollen würde, die Option ProcMon auf 800 Produktionsserver laufen zu lassen, ist keine gute Option.

Nachdem die Maschine nicht mehr ansprechbar war, generierte ich ein full memory dump. Ich bin nicht wirklich erfahren mit der Analayze solcher Memory Dumps, aber sehen wir mal ob uns das wohin führt.

Analysieren des Memory Dumps

1. Als erstes brauchen wir WinDbg. Der einfachste Weg ist die WinDbg Preview via Microsoft Store herunterzuladen.
2. Danach müssen wir den Symbol Server einrichten, damit wir auch etwas lesbares bekommen. Eine einfache und sinnvolle Methode ist die Umgebungsvariable: _NT_SYMBOL_PATH=SRV*C:\symbols*http://msdl.microsoft.com/download/symbols zu setzen. Das gute ist, auch andere Tools nutzen diese Umgebungsvariable um die richtige Symbol Server Konfiguration zu verwenden.
3. Herunterladen der WinDbg extension: DbgKit von Andrey Bazhan (weil die ursprüngliche Website offline ist, hier mein mirror link.
4. WinDbg öffnen und den Memory Dump laden (File > Open dump file).
5. Die Debugger Extension laden: .load DbgKit\x64\dbgkit64.dll (Der Pfad muss potentiell angepasst werden).
6. Sobald die CLI in WinDbg verfügbar ist, folgendes Kommando eingeben: !dbgkit.mm.
7. Ein zusätzliches Fenster öffnet sich. Das dauert nun ein paar Minuten. Zeit für ein koffeinhaltiges Getränk deiner Wahl.

Analyseergebnisse

Der Tab “File Summary” ist der nützlichste in unserem Fall. I hatte unterschiedliche Memory Dump (so um die 5) aber ich sah nur zwei unterschiedliche Patterns.

Das erste Pattern

Das ist sehr interessant - eine .ost Datei wird nur erstellt, wenn Outlook im “Offline Mode” arbeitet. Üblicherweise, aktiviert man den “Online Mode” in einem nicht-persistenten Umgebung (wie es bei der Verwendung von Citrix PVS üblich ist). Wir haben vor zwei Wochen auf Microsoft Office 2016 migriert und haben den Online Mode nicht erzwungen via GPO. Ab diesem Zeitpunkt haben wir es (wieder) erzwungen.

Das zweite Pattern

OneNote erzeugt sehr viele (und im Screenshot sieht man nur einige davon) binary cache Dateien. Es gibt keinen Weg diese zu deaktivieren. Da sind ein paar Artikel im Internet die beschreiben wie man mit Symlinks die Situation ändern / verbessern kann. Ich seh nur durch die Verwendung / Implementierung einer solchen Symlink Lösung andere Nachteile.

Abschließende Worte

Nachdem wir diese zwei Probleme identifiziert und gelöst / Workaround geschaffen haben, hatten wir keine korrupten VDAs mehr. Ich habe probiert einen einfachen Weg zu zeigen wie ein solches Problem analysiert werden kann und es gibt vermutlich noch viele andere Wege das Problem zu analyiseren.

Happy troubleshooting.