Wpf causes unwanted wisptis.exe

Hi, I hope all is well. I was wondering if anyone could teach me the following question.

If I turned off the โ€œTablet PC input serviceโ€, it would provide touch and stylus functionality. However, when I run the sample wpf application (from creating a new wpf project), it restores touch functionality and styles. Using the process handler, I see that this WPF application starts a process called "wisptis.exe", which happens to be a screen window and a touch process.

My question is. Is there a way for me to programmatically stop WPF from creating my "wisptis.exe"?

Thanks,

+4
source share
3 answers

Microsoft knows about the problem, but at the moment it is placed in the backburner. The error status is Closed as Pending. The problem seems to be over 2 years old.

http://connect.microsoft.com/VisualStudio/feedback/details/670149/visual-studio-2010-breaks-wacom-tablet-input

+2
source

I posted these instructions to the horrible Microsoft forums to help anyone who just hates unnecessary junkware that works all the time, but it should work for your purposes too. The trick is to leave the file in place, but not let Windows run it - and you can do this by removing the Execute permission from the file. With a little digging, you could probably figure out how to do this programmatically, although for obvious reasons, I would recommend not to do this on other people's computers during installation (if your program is deployed somewhere else).

Permissions are configured using ICACLS, available starting with Windows 7. (CACLS and the much older ATTRIB cannot change Execute permissions, which is all we need to change here.)

In the instructions, you will see the TAKEOWN command. At some point, Microsoft decided that you are just a visitor on your computer - Windows "owns" this file, so you usually canโ€™t change the file permissions, so the first step is to take responsibility for it. ICACLS can also establish ownership, but TAKEOWN is actually easier to use if you, the logged in user, are the intended owner, which is what it is.

Your user account must have administrator rights to complete this task. Open a command window (press Win-R, type "cmd" and press Enter). Enter each of these commands and press enter after each of them:

%systemdrive% cd %windir%\system32 takeown /f wisptis.exe icacls wisptis.exe /deny "NT AUTHORITY\SYSTEM":(RX) 

Then reboot. Poof, it has disappeared, and Windows will not be able to start it (although you can, if you really want for some reason).

If you want to restore permissions, run ICACLS with / grant instead of / deny.

Please note that a really useful Snipping tool for Windows requires wisptis, for some reason. I use it often enough to use the shortcut on the taskbar. Now I hold the shortcut for the awesome IrfanView image editing tool, which can do superb image capture using the command line. Google for all options, but I use "/ capture = 4", which launches IrfanView in capture mode to select a specific area.

+6
source

I had similar symptoms after installing the Windows .NET Framework 4.5.2 update. The takeown / icacls solution did not work for me, unfortunately, although I repeated a similar tip to rename the file in the recovery console. Taken from the wacom support forum , this worked for me: ( nb: wacom bit is irrelevant - I don't have a wacom tablet)

I managed to get rid of this problem by renaming wisptis.exe in "c: \ windows \ system32" for something else, as suggested above. However, for this I had to restart Windows, press F8 during boot up, go into the Recovery Console and from there select the immediate command. From the Repair Console command line, you can go to the hard drive on which Windows is installed (with console it not C :, you have to try all the drive letters to find This. In my case it was H :) and rename the file from there without any (even in safe mode it could be renamed from Windows) using the commands:

 X:\WINDOWS\SYSTEM32>h: (might take a few tries to find the right letter for the boot drive) H:\>cd \windows\system32 H:\WINDOWS\SYSTEM32>ren wisptis.exe wisptis.exe_ H:\WINDOWS\SYSTEM32>exit 

Then exit the recovery console and reboot into Windows as usual. The problem is resolved. Finally!

0
source

Source: https://habr.com/ru/post/1486269/


All Articles