No keyboard input

[privacyguy123]

You may experience an issue with Windows Terminal where keyboard input does not work. By and large, we've determined that this is caused by the "Touch Keyboard and Handwriting Service" being disabled.

If you're hitting this issue, make sure that the "Touch Keyboard and Handwriting Service" is not disabled. Certain "de-bloating" software (and apparently MSI Afterburner) likes to disable it or suppress it in the name of making your machine less understandable and "faster".

If you're experiencing an input issue that is not helped by exiting MSI Afterburner or re-enabling the "Touch Keyboard and Handwriting Service", please file a new issue.

Original issue content

Latest version of Windows Terminal. Tried clean installing multiple times, keyboard input works on everything else (as I am typing with it here ...) yes that includes powershell.exe and cmd.exe. What gives?

[Kein]

I have the same issue on 2004 test setup in VM. Workaround works but ¯\_(ツ)_/¯

[ilkersigirci]

In 2004, I am experiencing the same problem, workaround works though

[ghost]

Same observed on

• W10 x_64 Pro 2004 b19041.264
• WT 1.0.1401.0

Pasting into the terminal works in anycase, typing only with InputServiceEnabled = 0 but that causes the search window not accepting ENTER from the keyboard.

Other terminal sessions from CMD or powershell (v 7.0.1) apps do not exhibit the issue.

[sharpjs]

@n8v8R

InputServiceEnabled = 0 but that causes the search window not accepting ENTER from the keyboard.

Does that side effect persist after a reboot? IIRC, I experienced a similar side effect until I rebooted.

[jmartsch]

I have the same problem. The workaround from r33int works for me also to get keyboard input in Terminal... BUT in the Windows search function (pressing Win key and then start to type), the arrow keys and delete keys then don't work anymore:(

I will provide more info if you need it.

Windows 10 Insider Preview 19041.1 (vb_release)

[ghost]

@sharpjs

Does that side effect persist after a reboot? IIRC, I experienced a similar side effect until I rebooted.

Did not check previously but just found out that logging off, after the change in registry, and logging back on suffices and the search windows input is back to normal.

---

@jmartsch

BUT in the Windows search function (pressing Win key and then start to type), the arrow keys and delete keys then don't work anymore:(

Noticed that as well, just logging off and back on solved it on my node.

---

Which services those registry entries are referring to?

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Input]
"InputServiceEnabled"=dword:00000000
"InputServiceEnabledForCCI"=dword:00000001

[ghost]

Which services those registry entries are referring to?

It seems to be related to enabling/disabling

C:\Windows\SystemApps\MicrosoftWindows.Client.CBS_cw5n1h2txyewy\InputApp\TextInputHost.exe

Either the bug is in that app or WT has a problem communicating with it correctly.

[SupplelyBasil36]

When I just installed the new windows terminal from the microsoft store, when I want to write nothing is shown on the screen, even though I type random letters nothing is written in the terminal, I need help!

[aaugmentum]

Same for me, after I updated my windows to latest 2004, terminal doesn't accept input from keyboard, I tried clean install several times both with normal and preview versions as well as changing values in registry, nothing worked for me.

[sharpjs]

@LuisMontoya1404

I need help!

Have you tried the workaround posted above? link

[lisalander]

I recently encountered the same issue. on 19041.264

The posted workaround appears to fix my problem. I didn't have to logout or reboot.

[NicoVogel]

I also have the same issue.

• Windows version: 19041.329
• Windows Terminal version: 1.0.1401.0

The workaround did work for me as well, but the search bar did not work as intended. But as mentioned by @sharpjs a restart fixed it for me (comment).

I shortly investigated the different effects of changing the values from InputServiceEnabled (ISE) and InputServiceEnabledForCCI (ISECC). The following table shows the behavior on my machine.

Table explanation:

• Type
  • input = Windows Terminal input via keyboard
  • past = Windows Terminal input via past command (right click)
  • search = Windows search bar
• Value (val) equals the value in the registry and restart should be clear
• Result (res)
  • yes = works as intended
  • no = doesn't work as intended
  • (number) = explained below

Type	val/res	val/res	val/res	val/res	val/res	val/res	val/res	val/res
ISE	1	0	0	0	0	1	1	1
ISECC	1	1	1	0	0	0	0	1
restart	after	before	after	before	after	before	after	before
---	---	---	---	---	---	---	---	---
input	no	yes	yes	yes	yes	yes	no	no
past	yes	yes	yes	yes	yes	yes	yes	yes
search	yes	(1)	(2)	(2)	(2)	yes	yes	yes

Special Search behavior

1. The following inputs did not work: Delete, Backwards, Pos1, End, Arrow keys, Enter
2. The combination [CTRL + Backwards] did delete the word as expected, but leaves the symbol "□".

TL;DR

This workaround worked for me, but I only changed the value of InputServiceEnabled to 0. This change broke the windows search bar, but after a restart everything was fine.

Edit After two days of use of the highlighted setting, the windows search changed its behavior from normal to special search behavior 2.

[kvaranovich]

I am also experiencing the following issue. OS Name Microsoft Windows 10 Pro Version 10.0.19041 Build 19041

Setting InputServiceEnabled = 0 Windows Terminal started accepting inputs after this setting. There is a side effect, though. When I use Ctrl+Backspace combination in Windows search, the whole text is deleted, but weird character is inserted.

[r33int]

This workaround also seems to cause weird behavior with tab autocompletion. The tab input seems to be registered twice when pressing once. This is very disturbing. is anyone else facing this?

[EricZimmerman]

YES!!!

I have been trying to figure out why terminal has been double tapping like that for a long time! Great find

[EricZimmerman]

confirming reverting InputServiceEnabled to 1 fixes tabbing

[NicoVogel]

confirming reverting InputServiceEnabled to 1 fixes tabbing

@EricZimmerman So you are using InputServiceEnabled 1 and InputServiceEnabledForCCI 0 and this works for you? This combination worked only until I restarted my machine.

I also have the double tab problem

[EricZimmerman]

i had it at 0 to work around the issue. had double tab.

switched it back to 1 and it seems to be fixed, but i have not restarted my machine.

[rafavielma]

keyboard doesn't work happens to someone else, the solution they give disables win + v and other functions

[julianonunes]

keyboard doesn't work happens to someone else, the solution they give disables win + v and other functions

I was using Windows Terminal normally even after build 2004 and then keyboard input stopped working last weekend.

The workaround pointed in this link solved it without breaking hotkeys like win + v.

[rafavielma]

keyboard doesn't work happens to someone else, the solution they give disables win + v and other functions

I was using Windows Terminal normally even after build 2004 and then keyboard input stopped working last weekend.

The workaround pointed in this link solved it without breaking hotkeys like win + v.

InputServiceEnabled = 0 but that causes the search window not accepting ENTER from the keyboard.

[julianonunes]

keyboard doesn't work happens to someone else, the solution they give disables win + v and other functions

I was using Windows Terminal normally even after build 2004 and then keyboard input stopped working last weekend. The workaround pointed in this link solved it without breaking hotkeys like win + v.

InputServiceEnabled = 0 but that causes the search window not accepting ENTER from the keyboard.

Yes, it causes that. Not only enter, but also keys like backspace.

[rafavielma]

keyboard doesn't work happens to someone else, the solution they give disables win + v and other functions

I was using Windows Terminal normally even after build 2004 and then keyboard input stopped working last weekend. The workaround pointed in this link solved it without breaking hotkeys like win + v.

InputServiceEnabled = 0 but that causes the search window not accepting ENTER from the keyboard.

Yes, it causes that. Not only enter, but also keys like backspace.

And what do we do when it is solved, there are no answers only patches that are not useful, you cannot work with wsl2 like this.

[sharpjs]

@rafavielma @julianonunes You need to restart after applying the workaround. See the table that @NicoVogel made.

[DessertArbiter]

Any Alt shortcuts seem to work even when Terminal wont accept any other keyboard input. The Home and End keys also work while holding down Alt.

[ghost]

Tested with the recent WT release 1.0.1811.0 but the bug is still present. Whilst the workaround is a workaround with caveats wondering whether the developers are actually looking into getting this sorted any time soon?

Suppose that the OS implemented the \InputApp\TextInputHost.exe service for a reason and since both, OS and WT, are being developed by MS wondering what is the difficulty to get the WT app properly aligned with the OS code?

[EricZimmerman]

its ridiculous that this is still happening

[ghost]

developers seem rather content this not being a bug

Originally posted by @DHowett in https://github.com/microsoft/terminal/issues/4448#issuecomment-630977808

I’m going to say the intermittent nature of this bug made it seem fixed. :)

[DHowett]

Yes, take a quote from me out of context and it might appear that way. Look: the input stack in Windows is not straightforward, and we have engaged the input team in figuring out why keyboard input doesn’t work in certain app contexts. If we had any updates, you’d all be the first to know.

I’m going to lock this thread; not because I don’t think it’s a bug (it is), but because all your complaining sends an email to every single subscriber and that’s probably not how they want to start their Wednesdays.

[zadjii-msft]

Moving some relevant info from #7288

Windows 10 - 19041

On-screen keyboard also does not work.

Pasting from clipboard works.

If I hold 'alt' while typing Command Prompt will register input from the keyboard but only while I'm holding 'alt'. If I hold 'alt' while typing PowershellCore will register input from the keyboard but selecting any numbers changes the prompt to "digit-argument:" If I hold 'alt' while typing Powershell will register some input, no letters but ;'-=/ are accepted and selecting any numbers changes the prompt to "digit-argument:"

Still no updates on this thread, we're still trying to track down a way to debug this while someone's currently in this busted state, because there's no clear line of sight on what causes the OS to get into this bad state. If we knew what was triggering this bad state, then this would be much easier to debug.

[ghost]

If we knew what was triggering this bad state, then this would be much easier to debug.

TextInputHost.exe appears to have caused some grievance (unresponsive state) in other places

https://blogs.windows.com/windowsexperience/2020/01/30/announcing-windows-10-insider-preview-build-19555/

which seems been fixed just recently

https://blogs.windows.com/windowsexperience/2020/08/05/announcing-windows-10-insider-preview-build-20185/

Has recent insider version been tested against this bug?

[sharpjs]

@zadjii-msft If someone from MSFT wants to do remote debugging with my machine in the busted state, I am up for it. I'm available most of the time between 8AM-5PM PDT, any day of the week. I have Teams. @sharpjs on Twitter and Telegram. There is an email address if you'd like that.

[ghost]

I am also experiencing the same problem on a fresh install of WIndows and Terminal. If I can be of any help please let me know.

[nickpage221]

Moving some relevant info from #7288

Windows 10 - 19041 On-screen keyboard also does not work. Pasting from clipboard works. If I hold 'alt' while typing Command Prompt will register input from the keyboard but only while I'm holding 'alt'. If I hold 'alt' while typing PowershellCore will register input from the keyboard but selecting any numbers changes the prompt to "digit-argument:" If I hold 'alt' while typing Powershell will register some input, no letters but ;'-=/ are accepted and selecting any numbers changes the prompt to "digit-argument:"

Still no updates on this thread, we're still trying to track down a way to debug this while someone's currently in this busted state, because there's no clear line of sight on what causes the OS to get into this bad state. If we knew what was triggering this bad state, then this would be much easier to debug.

Follow up to my feedback above, the issue has suddenly and mysteriously stopped. All terminal types are working properly now. Since posting the only changes to my system were Nvidia drivers were updated (to 452.06) and system reboots.

Wish I had more info to help find the cause/solution.

[ghost]

Unfortunately updating my Nvidia drivers did not help. I am now at version 452.06 and still experience the same issues within Terminal. Thanks for the assist.

[johnhauhnar]

Same problem here with fresh install. Windows version 2004(OS Build 19041.388) I tried both the stable and preview version, same problem. Let me know if debug logs are needed @zadjii-msft

[swax06]

I had the same problem. For some reason Touch Keyboard and Handwriting Panel Service was disabled. I changed startup type to manual in properties and rebooted. That's it and windows terminal started taking keyboard inputs.

[NightWulfe]

Edit: swax06 beat me to it.

This happened to me as well. My experience may be entirely coincidental:

I had recently installed a drawing tablet. After doing so, I noticed the On Screen Keyboard would always appear on my login screen, even with the on screen keyboard disabled with the usual Windows Settings options. Annoyed by this, I disabled and stopped the "Touch Keyboard and Handwriting Panel Service" which resolved that issue.

Some time later after rebooting, Windows Terminal no longer accepted keyboard input. The workarounds specified earlier in the thread solved my issue, except for the known issues related to tab completion and hitting Enter in Windows Search. Unhappy with these workarounds, I reverted them and shelved Windows Terminal until this could be fixed.

At some point I remembered what I had done with the service and checked to see if it was related. I verified Windows Terminal was still not accepting input, and then re-enabled the "Touch Keyboard and Handwriting Panel Service" and rebooted. After that, Windows Terminal started accepting keyboard input again and I haven't had any problems since.

Those of you having issues, maybe see if this service is stopped or disabled?

[EricZimmerman]

my service was DISABLED as well.

i set it to manual and will reboot to see how it goes

[gfxonline]

I had the same issue for a while now and yes now I remember I actually disabled the "Touch Keyboard and Handwriting Panel" service as part of my usual Windows cleanup routine. I switched it back to manual and I can confirm the Terminal works perfectly after rebooting! Thanks for the suggestions @swax06 and @NightWulfe

[EricZimmerman]

OK, after a reboot, IT WORKS.

The world makes sense again!

[DHowett]

Just as a note, “cleaning up” Windows by disabling system services usually disqualifies you from complaining about weird bugs ;) and makes it very difficult for teams like ours to help you troubleshoot. It also has a higher than baseline tendency to outright break things.

[BobGallardo]

Same here. TabletInputService was disabled. Setting the startup type to manual has resolved the issue for me. Nice find!

b

[gfxonline]

Just as a note, “cleaning up” Windows by disabling system services usually disqualifies you from complaining about weird bugs ;) and makes it very difficult for teams like ours to help you troubleshoot. It also has a higher than baseline tendency to outright break things.

I didn't "complain" about it, I merely tracked the relevant issues on Github so I get emails about possible updates. By the time you mentioned the issue was not reproducible on your end I figured out it was something specific to my setup but I just forgot about this service entirely. Also the name "Touch Keyboard and Handwriting Panel Service" doesn't imply any harmful effect to non-touch keyboards, and since I never use any touch keyboards nor handwriting panels I figured it was pretty safe to disable this one. The built-in Windows "cmd" and "powershell" terminals were not affected by this change so I cannot really blame the Windows OS team, nor the MS Terminal team because you gotta admit that this is a weird dependency to have on a seemingly unrelated OS service, and I take full responsibility for modifying my OS so I will never "complain or whine" especially for an open-source project.

[ghost]

Just as a note, “cleaning up” Windows by disabling system services usually disqualifies you from complaining about weird bugs ;)

There is nothing weird about disabling unnecessary services like Touch Keyboard and Handwriting Panel on nodes that do not provide even the hardware. Basically you are likely disqualifying anyone having reported the issue there, even implying that user with such setup have not right to report a bug...

[BobGallardo]

I should have mentioned that I didn't disable the service to begin with. I'm not sure where that change came from.

"Cleaning up" Windows is ok and shouldn't disqualify anyone from looking for support, although it can make things more difficult to troubleshoot when all the relative information is not available. I agree that any changes to the OS should be disclosed when engaging support.

One last note on this service. The description states "Enables Touch Keyboard and Handwriting Panel pen and ink functionality" and that's it. Since my computer doesn't have touch support it would seem that I wouldn't need this service. It seems to me that if Microsoft were a bit more detailed in the descriptions of their services maybe this wouldn't happen.

b

[EricZimmerman]

what @gfxonline said. i am on a workstation with no touch anything. seemed unnecessary, but what do i know?

[NightWulfe]

Just as a note, “cleaning up” Windows by disabling system services usually disqualifies you from complaining about weird bugs ;)

TIL contributing to bug reports is considered "complaining" these days.

The only complaining I was doing was targeted towards the On Screen Keyboard. The only clean up I did was dealing with OSK ignoring both "Use the On-Screen Keyboard" settings (why are there two?!) and appearing on the login screen regardless. The fix I used is one posted around frequently, and the only one that works. Aside from renaming or denying full access to OSK.exe. Those would probably work, too.

No other application on this system other than Windows Terminal had any problem with "Touch Keyboard and Handwriting Panel Service" being disabled.

[zadjii-msft]

guys there was a ";)", he's being facetious

[ghost]

That is interesting, my "Touch Keyboard and Handwriting Panel Service" was also disabled by GPO. Once I resolved that and got the service back to Automatic and rebooted my Terminal is now working properly. Thank you all for your help!