App-V XenDesktop 7.0, XenApp 6.5 und Citrix Provisioning Services Appcrash

Mit den Citrix Provisioning Services, XenDesktop 7.x und App-V 5.0 gibt es noch so einige Probleme. Hier wollen wir diese kurz zusammenfassen und eine Konfigurationshilfe bieten. Merkmal einer solchen Konfiguration ist der AppCrash der App-V Anwendung. Wenn das passiert, geht teiweise nichts mehr. Andere App-V 5 Anwendungen laufen noch. die gecrashte Anwendung machmal gar nicht mehr. Merkmal ist der Stopfehler 0xc0000005

Dies ist ein Problem, dass ab XenDesktop 7.1 gelöst sein soll. Jedoch setzen viele Kundenumgebungen noch auf XenApp 6.5 mit PVS und wollen nicht auf die neueren Produkte gehen.

Der Fix soll wohl die neue Option "Cache in Device RAM with Hard Disk Overflow" sein. CTX139627. Der Fehler tritt aber anscheinend auch mit den 7.1er Komponenten und der genannten Option auf. Nicht immer mit dem Fehlercode 0xc0000005. Der Workaround dazu findet sich untem im Text.

Figure 1: Fehlermeldung Anwendung 1

Figure 2: Fehlermeldung 1 Anwendung 2

Figure 3: Fehlermeldung : 0xc0000005 AppV 5 Anwendung 1 und 2

Der Fehler deutet auf zu langsames Verhalten der Anwendung oder des Systems hin. Das Problem wird deutlich eingeschränkt durch die Aktivierung des Shared Content Store für App-V.

 Dieser kann gleich bei der Installation aktiviert werden:

appv_client_setup.exe /SHAREDCONTENTSTOREMODE=1 /q 

Oder mit dem folgenden Powershell Befehl:

Set-AppvClientConfiguration -SharedContentStoreMode 1 

Der Shared Content Store hilft jedoch nicht bei allen Anwendungen. Es muss klar sein, dass ein Absturz ausreicht, die App-V 5 SP2  Anwendung vollständig zu crashen.

Figure 4: Anwendung 2 läuft immer noch nicht

Unser PVS System muss schneller werden. Daher schalten wir zusätzlich  „Cache in device RAM“ für das PVS Image ein. Beide Anwendungen laufen nun, auch mit deaktiviertem Shared Content Store!

Figure 5: App-V 5 PVS Cache in device RAM

Da der Cache Typ „Cache in device RAM“ für viele Kunden keine Option ist (da die Maschinen hier mit entsprechend mehr RAM dimensioniert werden müssen), kann man als Workaround auch den App-V Cache der Endgeräte auf die persistente Platte umlegen (PackageInstallationRoot und IntegrationRootGlobal).
Mit einem Skript können diese Ordner bei jedem Neustart der Maschine gelöscht werden, so hat man die gleiche Konstellation als würden die Pfade im PVS Image liegen. Auch hier ist es möglich den SCS zu aktivieren. Dann werden halt nur die Symbolischen Verknüpfungen im App-V Cache auf der persistente n Platte gespeichert. 

Set-AppVClientConfiguration -PackageInstallationRoot "D:\App-V"

Figure 6: App-V 5 Client Konfiguration

Zusammengefasst: App-V 5 im PVS aktuell nur mit der Option „Cache to Device RAM“ oder verlegen der Pakete auf ein „persistentes“ Laufwerk (D:\). Bei jedem Neustart den Ordner löschen und neu erstellen, um wiederum einen „Non Persistent“ Effekt zu bekommen.

Getestet wurde mit:

• XenApp 6.5 HPR 2
• PVS 6.1
• App-V 5 SP2 Hotfix 2