Share via

App-V: On Virtual Registry Nomenclature

  • Article

In previous blog posts, I’ve discussed items related to App-V’s virtual registry, including the VREG subsystem itself and the new Registry Staging System introduced with App-V 5. I have also been explaining concepts and App-V nomenclature as well so I thought it was very timely to discuss concepts and terminology for our new App-V users with regards to how App-V captures and handles registry information.

Registry Opacity and Translucency

The two most common concepts in virtualizing registry keys and values are registry opacity and translucency. When the sequencer detects that a registry key being captured does not exist, it will mark that key as Opaque. This means it will not merge with the native registry key and will be completely isolated. No native registry values or sub keys beneath this key will be visible in the virtual environment. If the sequencer detects that a registry key being captured already exists, then the key will be marked as translucent which means that the views of the virtual and local registry will be merged and any existing values or sub keys will be visible.

 

You can modify a registry key’s opacity/translucency setting in the advanced sequencing editor either during sequencing or by editing the package after the fact. In the Virtual Registry tab, you can right-click the registry key and view/set the opacity/translucency:

  • Merge with Local Key = Translucent
  • Override Local Key = Opaque

   

Registry Pass-Through

Do not confuse the concept of translucency with the concept of registry pass-through. In some cases, the virtual registry needs to be explicitly bypassed for specific keys regardless of a package’s virtual registry configuration particularly for registry writes. This means that data written to these keys will write directly to (or attempt to) the native registry. In App-V 5, these settings are configured at the client level in a REG_MULTI_SZ value called PassThroughPaths in HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft\AppV\Subsystem\VirtualRegistry

In App-V 4, this value was called VirtualRegistryPassthroughEx and is documented in the following KB article: https://support.microsoft.com/kb/2750869/en-us

There are default entries in both App-V 4.x and 5.x. I would advise against modifying these but you can add values as situations warrant. Bear in mind that any data that is written to these keys will remain even when the application is removed or repaired.

 

Registry Reflection

Registry reflection works with registry bitness virtualization in the sense that it provides replication between the 32-bit and 64-bit registries with Windows running on 64-bit platforms. It essentially copies the registry keys and values between the 32-bit views (Wow6432Node) and the native 64-bit view. These include registry keys that deal primarily with shell integration such as (but not limited to)

  • HKEY_LOCAL_MACHINE\SOFTWARE\Classes
  • HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3
  • HKEY_LOCAL_MACHINE\SOFTWARE\EventSystem
  • HKEY_LOCAL_MACHINE\SOFTWARE\Ole
  • HKEY_CURRENT_USER\SOFTWARE\Classes

Registry Reflection is documented in more detail here: https://msdn.microsoft.com/en-us/library/aa384235(VS.85).aspx. When App-V 4.6 was released, it was the first version of App-V to provide support for 64-bit operating systems. This meant new logic was incorporated into the sequencer in order to copy the views between the 64-bit view and the 32-bit views when sequencing 32-bit applications. Virtual applications needed to be able to replicate what happens in native scenarios. Let’s look at one:

So you have a machine in which you have installed Windows 7 x64. By default, the 4-bit Wordpad is registered to handle .DOCX files. Native registry reflection also has this copied into the 32-bit registry view. 

A change has been made and now Office 2010 32-bit is now installed. This will register 32-bit Microsoft Word to handle .DOCX files in the 32-bit registry view. Native registry reflection will then copy this information into the 64-bit registry view so both 32 and 64-bit applications will trigger Microsoft Word 32-bit for handling .DOCX files.

This would work in reverse as well. Let’s say some number cruncher was breathing down your neck demanding 64-bit Excel. So you install 64-bit Office. This would register 64-bit Excel to handle .XLSX files in the 64-bit registry view. Native registry reflection will then copy this information into the 32-bit registry view so both 32 and 64-bit applications will trigger Microsoft Excel 64-bit for handling .DOCX files.

In App-V 4.6, this required a special subsystem which can actually be turned off for troubleshooting purposes by creating a DWORD value called DisableRegistryReflection with a value of 1 in HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\Softgrid\4.5\SystemGuard\Overrides.

In App-V 5, reflection is handled on the client and is triggered based upon bitness of the process. Whether or not the 32-bit application was sequenced on a 32-bit or 64-bit sequencer does not matter due to the registry staging subsystem. On a 64-bit operating system, when the package was sequenced on a 32-bit Sequencer, the registry staging system will stage the reflected keys to both the 32-bit and 64-bit registry views.