App-V 5: On the App-V 5 Virtual Registry

  • Article

I have been meaning to follow-up my previous discussions of the App-V registry staging subsystem with an article on the virtual registry in App-V 5. I will admit I am a little late to the follow up, however, as they say “better late than never.” In previous article I discussed registry staging and its effect on publishing and streaming. Now the discussion continues with how the virtual registry handles operations once the virtual registry has been staged.

The Virtual Registry in App-V was implemented in a much more streamlined way in version 5 than in previous versions. First of all, real hive files are packaged with the APPV package format. In addition, the real registry is used where the actual locations are state-separated while the Virtual Registry component provides the correct redirection and COW (copy-on-write) operations merging 3 elements into a single registry view:

  • The native registry
  • The immutable staged package registry (built from the registry.dat file within the package)
  • The user and machine COW registry

Like with file assets, the view of each merged registry is done for each package and package group (virtual environment)

Functionality

At runtime, registry operations are hooked, and special sauce is made to ensure the redirection, registry merging, and copy-on-write operations of changes are done.

Registry reads are done in an ordered approach by layer and you can easily confirm this with Process Monitor. The order is:

  • The COW registry is read first
  • Followed by the Package Registry (constructed from REGISTRY.DAT)
  • Finally the native registry for the requested location.

For registry writes, things are much simpler. Registry writes always go to the COW location corresponding to the original key that was opened. Registry data that is written to the user’s roaming registry is tokenized so that it is portable across machine boundaries.

Bear in mind, this is based upon the predication that the registry location is viewed as virtual (opaque) to begin with and was not excluded or configured to be translucent in the sequencer. There are special pointers contained in the registry that will govern opacity that I will mention later.

 

Registry COW Locations

The Virtual Registry will manage and track all COW locations for registry storage. The locations will vary depending on security context and type.

Roaming User Registry COW data will go here:

  • HKCU\Software\Microsoft\AppV\Client\Packages\<GUID>\REGISTRY
  • HKCU\Software\Microsoft\AppV\Client\PackageGroups\<GUID>\REGISTRY

Non Roaming User Registry and non-elevated Machine Registry COW data will go here:

  • HKCU\Software\Classes\AppV\Client\Packages\<GUID>\REGISTRY
  • HKCU\Software\Classes\AppV\Client\PackageGroups\<GUID>\REGISTRY

For Machine registry data coming from elevated processes, the Registry COW data will go here:

  • HKLM\Software\Microsoft\AppV\Client\Packages\<GUID>
  • HKLM\Software\Microsoft\AppV\Client\PackageGroups\<GUID>

 

Special Registry Key and Value Metadata

You may have noticed that for some keys, you will also see some additional data:

This data is not on all keys but when it is, it is reflective of the specific state of the key when responding to registry operations. Particularly, whether the key was previous deleted or if it was configured to be opaque and not merged with the other registry layers.

  • 0x00010000: Key Deleted
  • 0x00020000: Value Deleted
  • 0x00040000: Key Opaque

If the value above also contains a 1 at the end of the type, this means there are sub keys present stored within the value data.

Purging the COW

The Registry COW data is purged along with the rest of the user state when the package has been deleted or when the package is repaired with the –userstate switch.