Solved On-Screen Keyboard will only run from elevated command prompt

[c2357]

I recently noticed that I couldn't start the On-Screen Keyboard (osk.exe) from my start menu. Tried all kinds of clean-ups, but it would not run - not from the %windir%\system32 folder, not from start>run, not from an ordinary command shell. But it loads fine from an elevated command shell. It also runs from other user accounts. And it runs fine on log-on if enabled in the Ease of Access Center.
Does anyone know where its idiosyncratic behavior could originate from.:sarc:

 

[A Guy]

Welcome to Seven Forums c2357. Does it run fine in Safe Mode? If so, you might try performing a clean start to see if there is a conflict.

http://www.sevenforums.com/tutorial...ation-conflicts-performing-clean-startup.html

See if unchecking Tablet PC Components in windows features correct this behavior

http://www.sevenforums.com/tutorials/5023-windows-features-turn-off.html

If not, try the System Files Checker

http://www.sevenforums.com/tutorials/1538-sfc-scannow-command-system-file-checker.html

It may be a permission issue, but then the question is what changed it, and how?

A Guy

 

[c2357]

Thanks A Guy!
I had performed the 2 last suggestions to no avail, but by performing a Clean Startup I was able to identify the culprit. As I suspected (since osk ran fine in another profile) it loaded as it should after a clean start-up. But it allowed me to pin down the villain by starting my usual start up programs one by one. It quickly turned out that it was AutoHotkey (i.e. AutoHotkey_L) that interfered with osk. As soon as AH was running osk wouldn't.
I'm no expert, but in hindsight, its not that surprising - both hook to the keyboard. My guess is that AH's keyboard hook prevents osk from acting as keyboard input device. Except when osk is run from an elevated shell, in which case it overrules AH and takes the hook. Haven't tried it, but I suspect AH malfunctions in the later case.

(one minute later)

Well, after trying launching osk from an elevated command prompt AH manged to stay in business (hooking to the physical keyboard, not the osk induced soft keyboard) - but some struggle was taking place under the hood - the cursor/mouse coordination became rather erratic.

The solution seems to be to suspend AH before launching osk, since the shortcuts won't work on the on-screen keyboard anyway.

 

[A Guy]

Great, glad you figured it out, well done. Glad we could be of assistance. Thanks for posting your findings, it may help others. A Guy