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.

Symptoms

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

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

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;

HKEY_CLASSES_ROOT\Interface\{C247F616-BBEB-406A-AED3-F75E656599AE}

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

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.