GLADIATOR@MSFT

Adventures in Desktop, Application, and User State Virtualization

App-V: On COM Isolation and Interaction

App-V: On COM Isolation and Interaction

  • Comments 7
  • Likes

 

Through the history of Windows, the COM (Component Object Model) has been integral to application development the as an interprocess communication mechanism. The roadmap from DDE (Dynamic Data Exchange,) to OLE (Object Linking and Embedding,) to OCX (OLE Custom Controls,) to ActiveX – and so on – allowed and continues to allow multiple languages and development environments to develop applications on this language-agnostic platform.

Because COM facilitates communication channels and data exchanges between applications, it requires both significant consideration and planning when determining the feasibility of application virtualization. App-V has its own virtual COM subsystem which is designed to isolate the COM interactions from the local operating system. The primary way it does this is through GUID spoofing.

COM uses CLSIDs (Class Library Shell Identifiers) to identify all of its components and interfaces. These are labeled using GUIDs just as many other things are in Windows  Different component types are identified by class IDs (CLSIDs), which are Globally Unique Identifiers (GUIDs). Each COM component exposes its functionality through one or more interfaces ({7312498D-E87A-11d1-81E0-0000F87557DB} is my favorite because it is “blur.”) The different interfaces supported by a component are distinguished from each other using these identifiers. One of the strengths of App-V is that it prevents COM conflicts among native and virtual applications and among applications running in different virtual environments. App-V is also able to isolate native and virtual COM servers within a virtual environment.

When App-V hooks into a process, the virtual COM subsystem is able to intercept and virtualize COM object instantiations by dynamically cloning COM registration within the virtual environment using auto-generated CLSIDs and start instances of the cloned COM server. The GUID mappings will be maintained throughout the life of the process. While the hook model is different between App-V 4.x and 5.x, the overall process is very similar. When you combine applications into multiple virtual environments (DSC, Connection Groups) or package multiple applications together into a single package, all of these applications will still be able to communicate with each other at the application level through COM.

Basic Planning

For the majority of applications, you will likely only need to consider COM at a high level when planning. I like to use scenarios and I often do when I am explaining this to customers.

 

In the example above, we have a simple scenario. We have Application A (Word) and there is an embedded object type of Application B that can be inserted and modified leveraging the controls of Application B. Oldest and most known method as it goes all the way back to OLE. In the world of App-V this may still be needed with virtual applications. How do we facilitate this?

1.)    If your plan is that Application A is virtual and Application B is virtual – then you will have to either:

-          Package Application A and B together in a single sequenced virtual application package

-          Package Application A and B separately but join them via a unified virtual environment (using DSC with 4.6 or Connection Groups with 5.x.)

2.)    If your plan is that Application A is virtual and Application B will be locally installed – then you will need to:

-
          Configure COM integration/interaction with the local operating system. The method varies depending on the version of App-V you are using.

3.)    If your plan is that Application A will be local and that Application B will be virtual – then you will have to do one of the following:

-          Create an extension point (shortcut) to the local application (A) within the configuration of the virtual application (B) and will have to launch the local application using that extension point so it will be hooked.

-          Create an extension point (shortcut) to the local application (A) within the configuration of an otherwise empty virtual package. Bring that package and the virtual application (B) into the same virtual environment using DSC or a Connection Group (depending on what version you are using.)

-          Use the “RunVirtual” registry key if you are using App-V 5.0 to allow the local process (A) to operate inside the virtual environment of the virtual application (B.)

 

Because some applications may still need to communicate with the local operating system, there may be the need to adjust and fine-tune COM behavior for certain applications (as in the case of #2 above.) App-V historically has had ways of doing this.

 

App-V 4.x: LOCAL_INTERACTION_ALLOWED

This is a tag in the XML configuration (OSD file) of an App-V 4.x application. Whehn this tage exists and is set to TRUE, this means that BOTH object/eventing virtualization (spoofing) and COM GUID virtualization (also spoofing) are turned off. This DOES NOT mean the virtual COM or the virtual object subsystems are turned off. The objects will still be looked up in the virtual environment, but if not found, App-V will revert to the native OS and look there as well. This is why it is usualy a fairly safe thing to implement. The primary App-V 4.x hook DLL (SFTLDR.DLL) is still injected with all of its subsystems.

To enable local interaction, the OSD VIRTUALENV element is configured as follows:

<VIRTUALENV>

<POLICIES><LOCAL_INTERACTION_ALLOWED>TRUE</LOCAL_INTERACTION_ALLOWED></POLICIES>

</VIRTUALENV>

Objects/Eventing will be discussed more in detail and in a forthcoming post.

 

App-V 4.x: Disabling and/or Micromanaging Virtual COM

You can manage COM in more detail within App-V 4.6 by configuring the client registry. This is generally not preferred as it globally affects the App-V Client where LOCAL_INTERACTION_ALLOWED applies only to the application package. If you want to disable the Virtual COM subsystem, you can navigate to the following registry key and set the following value:

HKEY_LOCAL_MACHINE\Software\Microsoft\Softgrid\4.5\SystemGuard\Overrides

Value: DisableGuidMapping

Data Type: REG_DWORD

Value: 1

Outside of troubleshooting, I find it illogical and dangerous to disable this as a solution to any virtualization problem. I would only advise doing this as a troubleshooting step. Once you realize what may be happening you can simply apply a more granular approach to permanently fixing the solution by excluding COM GUID spoofing for the troublesome application. You do this through COM exclusions. First create a subkey called ComExclusions beneath:

HKLM\SOFTWARE\Microsoft\SoftGrid\4.5\SystemGuard

Then create a value called “Exclusions” with a data type of REG_MULTI_SZ and then you will list all of the CLSID GUIDs that you want excluded on each line.

The App-V 5.0 Virtual COM Subsystem

COM integration in App-V 5 does out-of-process (its own process) and in certain cases - in-process (within a process) COM registration (Office 2013 Click2Run.) COM is also handled a little more granularly in the dynamic configuration files in App-V 5.0. This is to encourage more handling of COM through configuration policy on a per-package or per-connection group basis. Within this policy, you can set one of three modes:

  • Off
  • Isolated (Virtualized)
  • Integrated (through in-process or out-of-process registration.)

The overall effects are outlined in the following boring chart:

 

 COM Mode in XML

 OS Integration

 COM Virtualization

     <COM Mode=“Off">

    </COM>

 No integration

 Off

     <COM Mode=“Isolated">

          </COM>

 No integration

 On – w/ GUID Spoofing

     <COM Mode=“Integrated">

      <IntegratedCOMAttributes OutOfProcessEnabled="false" InProcessEnabled="false" />

    </COM>

 No integration

 On – no GUID Spoofing

     <COM Mode=“Integrated">

      <IntegratedCOMAttributes OutOfProcessEnabled="true" InProcessEnabled="false" />

    </COM>

 Integrate out-of-process

 On – No GUID Spoofing

     <COM Mode=“Integrated">

      <IntegratedCOMAttributes OutOfProcessEnabled="false" InProcessEnabled="true" />

    </COM>

 Integrate in-process

 On – No GUID Spoofing

     <COM Mode=“Integrated">

      <IntegratedCOMAttributes OutOfProcessEnabled="true" InProcessEnabled="true" />

    </COM>

 Integrate both

 On – No GUID Spoofing

 

I felt it important that you get a sense of all of the possible permutations of COM policy configuration. Especially if you are toggling the sequencer defaults in the “Advanced” tab. All this does is set the default policy in the dynamic configuration file (deployment_config.xml) generated by the sequencer.

 

When “Allow all COM Objects to interact with the local system” is turned off, the COM policy will default to:

    <COM Mode=”Isolated”>

 

When turned on (checked) it sets it to:

    <COM Mode=“Integrated">

      <IntegratedCOMAttributes OutOfProcessEnabled="false" InProcessEnabled="false" />

    </COM>

 

COM Mappings and Exclusions in App-V 5.0

COM GUID Mappings are stored in a COM Class Maps located in the following registry locations:

Per User:

   HKEY_CURRENT_USER\Software\Microsoft\AppV\Client\Packages\{PACKAGE_GUID}\REGISTRY\USER\{SID}\SOFTWARE\Microsoft\AppV\Client\COM Class Map

Per Machine:

   HKEY_LOCAL_MACHINE\Software\Microsoft\AppV\Client\Packages\{PACKAGE_GUID}\REGISTRY\USER\{SID}\SOFTWARE\Microsoft\AppV\Client\COM Class Map

These are helpful when troubleshooting COM. Like 4.6, you can also add individual exclusions within the registry by adding the GUID as a REG_SZ value in

   HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Subsystem\ComExclusions

Use the value itself to give a description for humans to read :) For example:

   Value: HKEY_CLASSES_ROOT\CLSID\{7312498D-E87A-11d1-81E0-0000F87557DB}
   Data Type: REG_SZ
  
Data: Blur

Comments
  • Great explanation as always Steve! Thanks for it!

  • Very very interesting article, thank you for putting it out there.  I'm still trying to wrap my head around it all.  However, as an FYI, setting both the IP and OOP to true requires admin rights in service pack 2 (which is in beta), while in SP1 it does not.  

    Hoping someone can shed some light on that, and also why IP = true is said to be unsupported here-

    blogs.technet.com/.../microsoft-application-virtualization-5-0-integration.aspx

  • I cannot comment on software that has not been formerly released yet. What I can comment on is the fact that IP COM is limited in that in order to completely facilitate this, JITV (Just-in-Time Virtualization) modules have to be implemented. This has been for Office 2013 so IP *IS* supported in that case.

  • Thanks Steve, really appreciate you taking the time to respond.  I have a packaged software that requires integration into windows explorer, and after troubleshooting can and does work with IP = true.  Basically I am trying to understand what the downfalls are; is JITV always 100%?  Aside from (presumably) a delay in loading or eating up CPU cycles, are their issues with utilizing it?  Is there a way on the client side to verify that the JITV modules are working correctly?  We are noticing a small % of times the shell crashes (which is exactly what happens with IP = false), but without knowing more its hard to start debugging.

    I had missed that Office 2013 uses it, which is encouraging news.  Again, thanks for the response, and the article in general.

  • Andrew: QQ: Do you have Explorer configured to launch each window in a separate process? This is set under "Folder and Search Options"

  • Steve,

    Thanks for responding, sorry I missed your responce for a while.  I just tested with the explorer option on and off, and got basically the same result.  (It seemed slightly 'harder' to crash explorer, but still very possible with normal usage).

    Also for what its worth, I attended an App-V 5 class with Tim Mangan, and showed him the issue.  He felt strongly enough about it to have me put in a blocking issue forum post in the SP2 Beta forum (that way was easiest to get MSs attention).  This IS an SP1 issue also, again he just thought it was the easiest way to get MSs attention.

    connect.microsoft.com/.../explorer-exe-crashing-when-shellextension-loads-while-virtual-application-is-also-launching

    If there is any information that could be helpful, I would be more then happy to help.  In the forum I attached a mini dump of the error and the deployment.xml we are using, and you can additionally contact me through there.

    Thanks!

  • Andrew,

    Great that you filed feedback on Connect. That is the best channel for these types of issues outside of Premier Support. This will bring it to the attention of the appropriate devs and PMs.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment