Solution: COM Addin failure with Locally installed MS Office 2016 c2r

These days I see many queries in Microsoft technet forum related to COM Addin's not getting loaded into locally installed MS Office 2016 c2r version. So to help others, I have listed the possible solutions which I have gathered from my experience and from other blog posts in a single article below.


1. Sequence Microsoft Office 2016 addin's using App-V 5.1 Sequencer
2. Publish the sequenced addin's package in the client side which has App-V 5.1 client and  Microsoft Office 2016 c2r locally installed
3. Launch the Microsoft Office 2016 c2r Word/Excel using /appvve: or RunVirtual registry key to load them into the  published addin's virtual environment to test the addin's.
4. we see that the addin is not loaded.

You can find a similar possible reason for failure in the below link.

"The ProcessesUsingVirtualComponents registry value specifies a list of process paths that are candidates for using dynamic virtualization (supported shell extensions, browser helper objects, and ActiveX controls). Only processes whose full path matches one of these items can use dynamic virtualization.

By default, Explorer.exe and Internet Explorer are listed there. Therefore, when the iexplore.exe process runs, it has the APPVEntsubsystem32.dllloaded in Internet Explorer. When Office C2R detects that APPVEntsubsystem32.dll is loaded into Internet Explorer, it does not load jitv.dll or APPVISVSubsystem32.dll into Internet Explorer. As a result, there is no registry redirection support.

When the JavaScript that's running in Internet Explorer tries to create any ActiveX objects that are part of the Office C2R package, that operation fails and the Office C2R and SharePoint integration are broken. Office C2R and App-V dynamic virtualization aren’t designed to co-exist; therefore, Office C2R disables Dynamic Virtualization when it detects that AppV client binaries are loaded in Internet Explorer to prevent double hooking."

Solution 1:

Create the AllowJitvInAppvVirtualizedProcess registry key as shown below to fix this known issue.

Windows Registry Editor Version 5.00


If it doesn't work try in wow6432Node registry.

Windows Registry Editor Version 5.00


Solution 2:

If Solution 1 doesn't work , try with the latest App-V 5.1 Hot Fix. Always make sure to use the latest App-V 5.1 Hot Fix. (A minimum of Hot Fix 4 is required for this issue to be resolved.)

You can download the latest Hot Fix here: KB4018510

NOTE: Fixes that are delivered to the “out-of-box” versions of App-V and UE-V are first delivered for the “in-box” versions of App-V and UE-V in the monthly Windows 10 cumulative updates.Since updates are provided to windows 10 in-box App-V client first, it will not require the installation of the latest Hot-Fix. But the AllowJitvInAppvVirtualizedProcess registry key is required.

Solution 3: 

If Solution 1 & Solution 2 doesn't work then open the sequenced package using App-V 5.1 sequencer and expand it to local from the tool menu.

Once it is de-virtualized, check whether the addin works. If it doesn't work then there is some file/registry missing.In this case, procmon or spystudio can help in troubleshooting.

Solution 4: ( Credits: Roy Essers)

If running on 64-bit windows then export the full hive HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY, and import it into HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\ClickToRun\REGISTRY.

NOTE: This must be done every time office updates.

I believe mostly Solution 1 & Solution 2 will fix the issue if the package has been properly sequenced.

Related Articles:

App-V Sequencer 5.x cannot sequence apps with filenames "CO_x" (Error 0x8007139F). But it is possible !!

Recently I came across the App-V technical document stating that

"The App-V 5.x Sequencer cannot sequence applications with filenames matching "CO_<x>" where x is any numeral. Error 0x8007139F will be generated."

So I ran a quick test to confirm on the same.I used App-V 5.1 sequencer and App-V 5.1.86 client for testing.

During monitoring phase, I created a New folder in desktop for convenience.I then created 3 new files with different extensions (CO_123, CO_456.txt, CO_897.dll) and then proceeded stopping the monitoring phase. I was expecting that sequencer will throw an error or fail as mentioned in the Microsoft technical document. To my surprise sequencer completed without any issues. I was able to see the files in Package Files tab in the sequencer package editor.

To confirm, I also published the test package in a standalone machine and saw those files getting reflected.

UPDATE 6/22/2017: One of my friend Roy Essers had a query asking whether this happens when sequenced to PVAD. Since I didn't test this scenario in PVAD, I quickly ran a test by enabling the sequencer with -EnablePVADControl and gave c:\program files\CO as PVAD folder.

In that folder I then created the below files.

After creating I stopped the monitoring and sequencer didn't show any error even this time. It successfully created the package. Even in client testing it got succeeded.

So to finalize, App-V 5.1 Sequencer can sequence apps with filenames having "CO_<x>" without any issues. This is just a experimental test scenario and if anyone have faced the issue having CO_<x> in their package while sequencing, kindly comment below about the application. I will be happy to validate it further and update this blog post.

Windows 10 v1703 - Auto App-V unpublished package clean up

Earlier when we unpublish App-V packages it used to stay in the App-V cache location  and used to occupy unwanted storage space on the client machines. If we want to remove them to free up space we need to  do manual removal or using powershell command Remove-AppVClientpackage

With the release of the new windows 10 creators update v1703 App-V client provides options to automatically cleanup the unpublished packages.It requires restart.

This option can be enabled either by PowerShell or group policy or Registry.


Open PowerShell as administrator and run the below code.

Set-AppvClientConfiguration -AutoCleanupEnabled 1


Run the below code to get the status.


Group Policy:

Go to Administrative Templates-System-App-V-PackageManagement-Enable automatic cleanup of unused appv packages and select enabled.



Finally Microsoft have provided the much awaited feature to its users.

Remove all unpublished apps to clear package cache

Often I see queries related to clearing leftover package files after unpublishing them. And so here is a sample powershell code to remove all unpublished packages from the system to clear the space they were occupying in the package store.

$allpackages= Get-AppvClientPackage -all|Where-Object {$_.IsPublishedToUser -like "False" -and $_.IsPublishedGlobally -like "False"} | select Name


 ForEach($package in $unpublished)


Write-Host "$package"

Remove-AppvClientPackage "$package"

Write-Host "$package" removed.


NOTE: Test the code in a lab environment, as it doesn't support any error handling.

The case of missing shortcut Icon - App-V 5.X

Recently I have been seeing many queries regarding shortcut Icon not displayed after publishing an virtualized App-V 5.x package. The answer would be quite simple. But I would like to demonstrate it with a simple example so that it can shed some light.

Let us assume a person X has sequenced an application say example Adobe Reader application. He is doing some manual clean up in the package editor. He removed some junk entries to keep the package clean. He also removed the Installer folder that has the installer cache (.msi, .mst, .msp)captured from the installer package as he felt it is also unnecessary junk entries like all others do.

After completing sequencing, he published the package to the machine in a standalone environment and saw that the shortcut icon is missing. He was wondering why the Icon is missing. He came back with a query as why the Icon is missing even after successful sequencing.

Now lets troubleshoot for him. First let's edit the shortcut for icon. We can see that it is looking in %ALLUSERSPROFILE%\Microsoft\AppV\Client\Integration\.....\SC_Reader.ico.

Lets take Procmon capture to get a proper solution. We can see that it is searching for SC_Reader.ico in  the Installer location and the path is not found clearly from procmon trace. When checked manually in the %Allusersprofile% we do see that the Installer folder is missing. This is because the person X has removed it from the package considering it as Junk entries earlier.

We can clearly see that after doing a fresh sequencing of the application that the Icon files are indeed kept in the Windows\Installer folder.

So to conclude do not remove files and folders blindly considering it as junk entries. Do not remove Windows\Installer completely. Perform cleanup with caution. Make sure if removing the Installer folder completely will not affect the functionality.