App-V 5: Further into COM and Dynamic Virtualization

  • Article

It has been addressed to me by the MVP community that more clarification is needed with regards to the architecture of how App-V 5 implements COM and how that may now differ as a result of the changes in Service Pack 2. The differences are simplified to the difference between the standard COM virtualization subsystem for normal virtualized applications and how Dynamic Virtualization handles COM objects for native processes that do not initially start off running virtually.

COM Virtualization

I have included a visual diagram to represent how the base virtual COM subsystem works to process virtual COM in-process and how out-of-process COM servers are managed in conjunction with the App-V Client Service and the Virtual Services component in preventing COM server conflicts among native and virtual applications and among applications running in different virtual environments.

The COM API’s are hooked by way of the injected App-V DLL. Depending on the COM settings, the Virtual COM service will be responsible for dynamically cloning COM registration within the virtual environment using generated spoofed GUIDS (or CLSIDs if you prefer that term – I use them interchangeably.) It will maintain a per-package (or Connection Group) GUIDS mapping of these spoofed-to-actual GUIDS. It will also be responsible for instantiating the cloned COM server(s) needed.

 

Enter App-V 5 Service Pack 2 and Dynamic Virtualization

Do not confuse the above with the added support for Dynamic Virtualization (also may be referred to as just-in-time virtualization or JITV.) The basic concept behind Dynamic Virtualization is that it allows the virtualization of shell extensions and ActiveX controls automatically within the native processes which would house them (Explorer.exe and Iexplore.exe) allowing for more tighter integration with the operating system.

Dynamic Virtualization modified App-V to allow:

  • Multiple Virtual Environments (VEs) to be associated with a single process.
  • Processes not running as a virtual process to have VEs associated with it.

 

App-V 5, through dynamic virtualization, allows virtualization of an in-process COM object implementing a shell extension or ActiveX control from the process that hosts it so long as that process appears under the ProcessesUsingVirtualComponents configuration item within the registry. Dynamic virtualization switches on for a thread that is executing within the object’s code or other code that is called from the object – rather than at the process level with standard virtualization. You can read up more on Dynamic Virtualization in a previous article mentioned here: https://blogs.technet.com/b/gladiatormsft/archive/2014/02/05/app-v-5-on-run-virtual-rds-run-virtual-virtualizable-extensions-and-dynamic-virtualization.aspx

A native process never has a package’s virtual environment associated with it by default unless it is hooked by App-V. Without dynamic virtualization, the only way for it to be hooked and associated with a primary VE would be to have a shortcut configured to the application within the package (in the case of App-V 5, also configured within dynamic configuration as being a virtual application.)

With dynamic virtualization, a process can have secondary virtual environments. These secondary virtual environments are differentiated from the primary virtual environment in that they are associated with one or more DLLs that are loaded into the process, and are used for virtualization only when they are dynamically activated and associated with a particular thread of execution. For any thread in which dynamic virtualization has not been activated, virtualization will be controlled by the primary virtual environment, if any.

When a shell extension DLL handler from a particular package is loaded into a native process or a process from a different package, a new secondary virtual environment will be created to associate the shell extension’s package with the process. When a thread of execution enters that DLL, dynamic virtualization will be switched on for that thread only and associated with the correct VE. When the thread exits the DLL, dynamic virtualization will be switched off for that thread, and finally, when the DLL is unloaded from the process, the corresponding secondary VE will exit.

If you want to control Virtual ActiveX controls (huh-huh – cheap pun there) in the old fashioned way for Internet Explorer where you launch a Shortcut to IE within the virtual environment, and not allow any other native instance of IE to launch that control you will want to remove Iexplore.exe from the ProcessesUsingVirtualComponents key within the registry key at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Virtualization.

I would advise against turning off Dynamic Virtualization altogether as the dynamic virtualization features work great with the shell extensions that would be leveraged by Explorer.

It’s actually not entirely new to Service Pack 2

Dynamic Virtualization was actually part of the flattened Office 2013 package from the initial release of App-V 5.0. The Integration subsystem included with Office allowed for native processes that needed to load a DLL from the Office package – i.e. MAPI.