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.

3 thoughts on “App-v and wisptis.exe

  1. Andy Parry Reply

    Hi – reference to the solution titled Microsoft Support Solution – 2014-10-15 , this will also work with App-V 4.6

    You should already have an ObjExclusions set to resolve problems with App-V 4.6 [and 5] a previous hotfix caused [KB2984972] – in our environment that is set to 95.

    So the path for App-V 4.6 for us is

    Type: Reg_SZ
    Name: 95
    Value: TermSrvReadyEvent

    So now the new one, as above…with this new path..and set to 96 in our environment is as follows:

    Type: Reg_SZ
    Name: 96
    Value: {773F1B9A-35B9-4E95-83A0-A210F2DE3B37}-running

    This is working for Windows 7 and also for our Windows 2008 R2 RDS / Citrix XenApp servers – all with App-V 4.6 and App-V 5 on.

  2. Les Butler Reply

    We had this issue and it was a pain.

    The wisptis.exe process running as the system was fine, it was the instance spawned that was running as the user that was causing the issue. I am assuming there was some kind of invisible dialog back that couldn’t be brought into focus that was location the mouse.

    What I did was create a dummy App-V 5 package that did nothing, really. But utilised the scripting features so that on publish it would carry out an icacls command on the wisptis.exe to deny Users access to execute. And this is what worked for us. System still had access to the exe, so denying the user access in our vm environment was a fair trade off as they dont use tablet type devices at all.

    • Les Butler Reply

      apologies for typo’s

      I am assuming there was some kind of invisible dialog box that couldn’t be brought into focus that was locking the mouse.

Leave a Reply

Your email address will not be published. Required fields are marked *