When Local Applications Are Started By App-V

Not long ago we had the problem that an App-V application started a local instance of Acrobat Reader DC and that Reader always crashed upon being called by the application a second time. So on a fresh system with a new user profile the call functioned exactly one time. Thereafter the Reader always crashed.

The real error isn't the application crashing but rather what is happening in the background.

This was only apparent to me after I was able to look into the problem. The registry key for Acrobat Reader DC is placed into the virtual App-V environment if the Reader registry key doesn't already exist in the user profile. This happens, for example, if Acrobat Reader DC has never been started before by the user. The registry key placement happens under the guise of the PackageID of the applicable App-V application when that starts a local application:

HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\Packages\<PaclageId>\Software...

This would occur by the way for any other application that later generates a key under HKLM and then is first started by an App-V application. The start happens within the virtual environment and thus registry settings that would normally be generated upon starting a program for the first time instead land in the virtual registry of the calling application.

Even better: if additionally directory folders are defined for the user profile in the App-V package that also affect the target application (%Appdata% exists in the App-V package), any files placed there (.ini, .properties) are also saved in the virtual environment.

%appdata%\Microsoft\AppV\Client\<PACKAGEID>\AppData\<Folder><FILE>

Even worse: if more applications use the profile, keys and files accumulate for the applications in multiple virtual environments and the user profile can become unnecessarily large.

Now, in the case of the PDF printer driver for Acrobat Reader DC, on account of a particular registry key that already exists in the App-V environment, upon a subsequent start it always comes to a crash. It doesn't matter which App-V application uses Reader. The crash happens regardless.

Solution ideas:

For one thing, one can see to it that the aforementioned registry keys and files already exist in the system. This of course requires effort. As an alternative there is an App-V registry key Pass-Through-Path:

HKLM\SOFTWARE\Microsoft\AppV\Subsystem\VirtualRegistry
REG_MULTI_SZ: PassThroughPaths

A PassThroughPaths setting defines registry keys from the system that cannot be overwritten by the settings in the App-V package. One of these keys affects Group Policies for example. Should Group Policies be in effect when a package is sequenced, the settings are taken nevertheless from the system upon which the package is being executed and not from the policies from the virtual environment.

For example, for Acrobat Reader the PassThroughPaths HKLM\Software\Adobe\Acrobat Reader can be used so that the application runs error-free and registry keys are not placed in the registry in the virtual environment. Unfortunately this won't help with configuration files. Here one needs to pay attention to what is defined for the package.

Summary: The PassThroughPath Key can avoid too much garbage from landing in the virtual registry and in the case of Acrobat Reader DC it can even be a global solution for problems with the application.

Consideration should be given to Profile Management in order to better solve the problem. For example Microsoft UE-V can also be a solution here, since the settings are saved under the application name and the App-V domain in the user profile or in the user registry must not be a component of the user profile (but can be).