App-V 5, ConfigMgr compliance and fixes

App-V 5 has recently gotten hit by two odd behaviors relating to an update and .NET Framework 4.5.2.

KB2984972 was released as an update for RDC, and caused some havoc both for App-V 4 and App-V 5. The workaround is documented in the article and essentially allows anyone to remove the unfortunate end-user experience by adding some registry keys.

.NET Framework 4.5.2 was released and quite early on people started noticing that a freeze could be experienced when using certain App-V applications. The culprit seems to be the processes wisptis.exe, and the issue could temporarily be worked around by terminating the process.

App-V 5 got hit by two issues that both were resolved by adding registry keys under the registry key ObjExclusions. The Gladiator has written an article that details more about this registry key, the purpose of it and the effects of it. The article is focused on App-V 4, however the knowledge and concepts still apply to App-V 5.

Under (HKLM\Software\Microsoft\AppV\Subsystem\ObjExclusions) this registry key there are a lot of registry keys starting at 1 and going upwards. Each registry key contains a value (oh, really?) that is the name of an object that is not virtualized.  Anyone can append new values by using the next available number. Aaron Parker wrote a great article on howto leverage Group Policy to add the requested registry keys to resolve the issues for KB2984972.

Let’s detail the fun fact about this registry key;

There are in a default installation of App-V registry keys from 1-92. On any given default installation the next available number we can use is 93. We now have two issues and would therefore end up with two extra registry keys (93 and 94). My guess is that Microsoft might potentially include these two above recommended registry keys in a future installation of App-V when a new version comes out. Forcing these values to be added to a specific number in the series could potentially throw other valuable exclusions out the window…

Therefore I personally voted against Group Policy (Preferences) and decided to go the route of ConfigMgr Compliance Settings.

By creating a configuration item I can achieve the following;

Detect if the specific value is already in the list
Find the next available number to create a new registry key in
Append the value if it doesn’t already exist.

In the end, this is what I came up with;


Detect if the App-V client is installed;


Two checks for each specific registry key;


Create a rule set that will allow for remediation;


Scripts part of the Configuration Item. This sample is from the fix for KB2984972.


$regKey = "HKLM:\SOFTWARE\Microsoft\AppV\Subsystem\ObjExclusions"
$p = Get-ItemProperty $regKey
$kb2984972 = $p.PSObject.Properties | where { $_.Name -match "[0-9]" -and $_.Value -eq "TermSrvReadyEvent" } | select-object -ExpandProperty Name -ErrorAction SilentlyContinue

if(($? -and ($kb2984972 -ne $null))) {
else {


$regKey = "HKLM:\SOFTWARE\Microsoft\AppV\Subsystem\ObjExclusions"
$p = Get-ItemProperty $regKey
$topvalue = $p.PSObject.Properties | Where-Object { $_.Name -match "[0-9]" } | Sort-Object -Property Name -Descending | Select-Object -first 1 -ExpandProperty Name
$topvalue = 1 + $topvalue

Function New-RegistryKey([string]$key,[string]$Name,[string]$type,[string]$value)


#Split the registry path into its single keys and save

#them in an array, use \ as delimiter:

$subkeys = $key.split("\")

#Do this for all elements in the array:

foreach ($subkey in $subkeys)


#Extend $currentkey with the current element of

#the array:

$currentkey += ($subkey + '\')

#Check if $currentkey already exists in the registry

if (!(Test-Path $currentkey))


#If no, create it and send Powershell output

#to null (don't show it)

New-Item -Type String $currentkey | Out-Null



#Set (or change if alreday exists) the value for $currentkey

Set-ItemProperty $CurrentKey $Name -value $Value -type $type


New-RegistryKey $regkey $topvalue "String" "TermSrvReadyEvent"

As a final treat. Here is the Configuration Item – ready to be imported into ConfigMgr.


2014-12-07 – Sebastian Gern stated an additional registry key for WISPTIS. The Configuration Item is also updated with the new settings.

App-v and wisptis.exe

Some applications that are virtualized with App-V 5 have caused issues with wisptis.exe –  a process to handle the input of pen-enabled devices. image


When an application that uses a .NET Framework(WPF, silverlight, SCOM / SCCM console, App-V UI etc) 4.5.2 is virtualized on any version of the App-V 5 client there is severe mouse-lag or hang.

Reproduce the issue

Connect a device which uses the Tablet Input service – most commonly Wacom-devices. Any WPF application based on .NET Framework 4.5.2 can cause the issue – for example using Chrome to access Outlook Web Access and then pressing “New message” (will use Silverlight) to generate a new email will spawn the wisptis.exe. The mouse freezes. If the process (wisptis.exe) is terminated mouse responsive will return to normal. The below is the process start of wisptis.exe

Process 5836 starting at 000000013F5AD9C8 C:\Windows\System32\wisptis.exe 11:24:08.939: [6388/6532] NtTerminateProcess( ProcessHandle=0x4f8, ExitStatus=0xc000042c ) => 0

The attempt to start this process fails with an STATUS_ELEVATION_REQUIRED code.

(credits to Paul Richards for the above info)

Public Workarounds

It seems that reverting back to .NET 4.5.1 has resolved the issue for quite a few people. If your application actually requires the .NET Framework 4.5.2 version that is of no use as a workaround. Installing the below hotfix may improve the issue aswell, however the successrate so far is low;

Mouse drawing is displayed incorrectly when the screen resolution is restored after a full-screen application stops on a Windows 7-based computer that has a multitouch screen installed

(while you are at it – apply this one aswell: Tablet PC Input Panel cannot be moved after you install update 2973201 in Windows 7 or Windows Vista )

Obvious workarounds

WISPTIS.exe is a process to handle the pen input, and therefore we can reduce our impact by completely disabling the the functionality. The policy can be find under;

User Configuration – Administrative Templates – Windows Components – Tablet PC – Cursor image

You can also disable it as a service (applicable on Windows 7 – named “Touch Keyboard and Handwriting Panel Service” for Windows 8): image

I haven’t personally confirmed this and so far this seems extremely intrusive as it completely disables the functionality for all applications.

Community discussed workarounds

WPF uses an interface, documented on MSDN, to determine if this is a tablet / touch enabled device. If you, inside the App-V 5 package while sequencing, edit the following registry key;


Change the default value (to something else), and then set it to Override Local. image

This obviously breaks the input functionality, however only for the virtualized application.

(Thanks Paul Richards for the above suggestion – brilliant in so many ways)

Microsoft Support Solution – 2014-10-15

This is the Microsoft suggested solution. Apparently App-V makes an attempt to start a second process, and therefore the lag is experienced. Create the following registry key on the App-V client machine. Location:“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Subsystem\ObjExclusions” Type:       Reg_SZ
Name:     93
Value:     {773F1B9A-35B9-4E95-83A0-A210F2DE3B37}-running

The number 93 is used in this because 93 is the first available number in a default installation. This might be higher if your installation has more object exclusions.

Thanks Paul Richards for the update

Long-term resolution

Microsoft has released an informal article (Sebastian Gernert posted it), and as a far as we can see the recommended changes are available in App-V 5.0 SP3

Interesting topic

If you are a heavy user of Wacom hardware – see this guide of Vizibler that hopefully can improve your situation.