Share via

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.

Comments

  • Anonymous
    March 29, 2016
    The comment has been removed
  • Anonymous
    March 29, 2016
    I was able to install AppvManage and the error that it trapped did not help.

    v.COM - VCom [6616]-[5856] Error: failed to read the registry list of VCOM CLSID remapping exclustions error =2
    Interpretation from Appv Manage: This message appears to be a benign but in the client code and should be ignored.
  • Anonymous
    April 19, 2016
    For something like this, we would need to find out how the object is being creating? is it a surrogate? Out-of-process? When you say printer is mapped, what do you mean? A locally installed printer driver?
  • Anonymous
    August 30, 2018
    Can you explain where Global publishing is required in relation to this topic as its continues to be very unclear to me?Global Publishing is a problem for us in our SCCM environment as it requires Device collection targeting which does not fit in with our User App self-service systems.