Terminal: No keyboard input

That's certainly unexpected - does this repro with any number of tabs?

Could you share the actual version number from the Terminal about dialog? That info makes it a lot easier for us to track bug reports, since "latest version" could either be "the latest release" or "built from master", and both of those versions change over time compared to when the bug was filed.

There's another bug floating around where focusing the window by clicking on the tab doesn't actually focus the terminal control - does clicking on the "terminal" are of the window do anything?

I'm pretty sure no one on the dev team is seeing anything like this, so it'll be pretty hard for us to fix this bug without more information somehow. Maybe if you could build form source and debug to see if Terminal::SendKeyEvent is getting hit?

Windows 10 build is Microsoft Windows [Version 10.0.19041.21].
Terminal version is 0.8.10261.0 from the Microsoft Store.

Problem doesn't seem to be focusing, no matter where I click I can't get keyboard input at all.

Perhaps you can talk me through this fix?

Bug has came back after a clean install - I wish I could remember how to recreate it, I suspect a Windows Update on Insider is messing with it perhaps?

Bumping this. I see a blinking cursor but still unable to type in Windows Terminal.

I too am seeing the issue. It has happened to my twice. I can type most special characters i.e.

• _ = + [ { ] } ; : " " < , > . ? / .

Cannot type any letters or numbers. No special characters on the numbers using shift.

Not sure how it happened but I think in both instances I was using a terminal split screen. When I clicked away from the terminal and came back to it a short bit later the issue was there. I believe the only fix for it at the moment is reboot the machine and I can then type again.

Version: 0.8.10261.0
Windows Insider Build: 19559.rs_prerelease.200131-1437

Also notice what I feel is a large number of Console Windows Host processes running but not sure if this is related. Currently no Terminals or Consoles opened on my desktop

Created a Dump file of the Terminal Process if that will help in anyway at all let me know how to get it to you.

This is happening to me as well, quite frequently.

Terminal works fine for some time then stops accepting keyboard input for Ubuntu Wsl2 container.
confirmed MCrank's observation that certain special characters still work fine.

if i open a new tab or close and reopen no change.
if i restart terminal app no change.

if i open a powershell tab it works for a short time then exact same issue happens with it so this isn't limited to wsl2 containers oddly enough.

stopping and restarting the LxssManager service seems to restore keyboard input for a period, i didn't think that would affect powershell, so not really sure why, just reporting what i'm seeing in case it is helpful tracking this bug down.

this started happening after the last update, and is is happening frequently enough to make terminal almost unusable and i work all day long at the command line so that is a serious workflow interruption for me.

this last time, restarting lxssManager didn't do the trick and i noticed that start menu, and search also didn't respond to keyboard input even though all other apps still work fine. not sure if this is the same issue? or related?

I know you said "everything else," but when input dies, can you still type into the start menu search box or the feedback hub? Those are both using the modern app platform, where powershell.exe and cmd.exe are not. Looking at a possible input platform issue that's broader than just terminal.

@DHowett-MSFT I'm on build-19564 and I'm also seeing this, I can confirm it's also happening in the windows start menu and feedback hub, so I confirm that might be broader than windows terminal.

when this occurs i cannot type into start menu search or feedback hub or cortana.
i completely disabled cortana in case it would help, and it has not.

Windows: 19569.1000 (insiders preview)
Windows Terminal Version: 0.9.433.0

That's certainly unexpected - does this repro with any number of tabs?

Could you share the actual version number from the Terminal about dialog? That info makes it a lot easier for us to track bug reports, since "latest version" could either be "the latest release" or "built from master", and both of those versions change over time compared to when the bug was filed.

There's another bug floating around where focusing the window by clicking on the tab doesn't actually focus the terminal control - does clicking on the "terminal" are of the window do anything?

I'm pretty sure no one on the dev team is seeing anything like this, so it'll be pretty hard for us to fix this bug without more information somehow. Maybe if you could build form source and debug to see if Terminal::SendKeyEvent is getting hit?

I did build and debug and the Terminal::SendKeyEvent doesn't trigged. My problema starts when I enable the Windows Insider and install updates.

Also can't type when starting with PS tab. Then I create cmd tab - now i can type, until change tab focus to other window or tab. Then again keyboard input not works. Remove and reinstall terminal not helps.
Windows 19041.113, (Insiders preview)

Can confirm this also happens on Windows Insider build 19569. A cmd tab does work within Terminal, but WSL and Powershell do not accept any keyboard inputs except a few special characters (alt+<, alt+>, etc.)

Windows Terminal version: 0.9.433.0

Maybe it has nothing to do with the current issue. But maybe this is a common problem with modern apps.

I often encounter problems in Windows Search where I cannot type. This phenomenon is more easily encountered with certain Win32 IMEs, such as Baidu Pinyin. This phenomenon is rarely encountered after using Microsoft Pinyin, but it is not completely absent. Reopening the search window after some time, the input may works.

I always thought it was a compatibility issue between modern app and legacy Win32 IME. But occasionally, this can also happen with Microsoft Pinyin. It is a modern app. In addition, the problem persisted during the two-year Insider experience.

I haven't encountered this problem in the Windows terminal, because the old version of Windows terminal did not support IME, and the line ending issue, I have not used it for a long time. If I encounter a problem with Windows terminal and IME, I will provide feedback.

And if you doesn't have an IME, it may be an insider issue:

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

• We fixed an issue where input would stop working in some places if clipboard history (WIN + V) was dismissed without pasting anything.

The "some places" only be modern apps, all win32 applications are unaffected.

Windows Insider build 19577 seems to have fixed this issue for me (yay!)

I'm pretty sure no one on the dev team is seeing anything like this,

I have been occurring since 0.8
No direct input. Can be entered through the IME (Microsoft IME).
Probably most Japanese Windows 10 and wt users have encountered this issue.
Is it difficult for a dev team to test in a Japanese environment?

Windows 10.0.19041.113
WT 0.9.433.0
日本語キーボード (106/109 キー)

We see this _occasionally_, and we're following up with the right team internally. It looks like there's something up in the input stack; we cannot say for sure whether Terminal is the cause of the issue or another victim.

If somebody has a _consistent_ repro that we can do on our own machines, it would be very helpful when we talk to that team.

Thanks for the Teams @DHowett-MSFT 😃

I tried to WT (Preview) 0.10.761.0, but it's still happened.

Really hope to solve it somehow. 🙏

p.s.

• There is no problem with PowerShell 7 GA release.
• Problem only in WT (tried these each shells Windows PowerShell, cmd, PowerShell, Azure Cloud Shell).
• I am always using with default settings.

modified 23rd Mar, 2020

• Not yet fixed in Windows Terminal Preview v0.10.781.0

This has just started happening to me as well. Repair/reset/reinstall did nothing to fix the problem. I can type everywhere else except for the Windows Terminal, where I can only type some special characters as some other people described above.

This is on Windows Terminal Version: 0.10.781.0
Windows 10 Education Build 19041.153

Same trouble happens.

• Windows 10 19041.153
• WT 0.10.781.0
• Japanese 106/109 key with ATOK Pro(Input method)
  
  
  
  • without ATOK, same behavior
  
  

Yes, I seem to have the issue as well.

• Windows Version 10.0.19587 Build 19587
• WT 0.10.781.0
• English(US)

Can also confirm this issue.

• Microsoft Windows [version 10.0.19041.153]
• Terminal v0.10.781.0
• French (FR)

Can confirm this too.

• Windows build 19603
• Terminal v0.10.781.0

No text input working on any WT tab, but they work in the actual apps.

Just a quick aside, installing the latest Fast Ring of 19608 seems to have solved it so far. I'm able to type in all windows of the terminal again.

I'm on 19592 and I haven't seen this happen in a while. Feeling lucky :)

I am on the latest Slow Ring (19041.207) and I see this as well.

To everyone in this thread who's hitting the issue:

Next time it happens, can you launch the _Feedback Hub_ and use the "Advanced Diagnostics" section to capture diagnostics in the Input and Language category, Input Lag subcategory?

Click Start Recording, and then enter a few characters into the Terminal.

Move back to the feedback hub and then click Stop Recording.

You'll get a new diagnostic log entry:

Select File Location, and e-mail me the diagnostic archive inside that folder or attach it to OneDrive and share a link. Please note that it might contain personally-identifiable information (like what characters you entered during the recording phase.) My e-mail address is on my profile.

Thanks! This will go a long way to helping us get to the bottom of this issue.

If any of you manage to get it to start happening while you’re recording, instead of just capturing it when it’s already happened, that would be immensely useful. Please let me know if that’s the case in the email :smile:

I had a version of this problem on a fresh install of Windows 19041.207 from ISO. It affected _only_ Windows Terminal; Search and other modern apps worked fine. I was able to resolve it by setting the following registry values and relaunching Terminal.

HKLM\SOFTWARE\Microsoft\Input:
  InputServiceEnabled: 0
  InputServiceEnabledForCCI: 0 # see note in edit 2

_EDIT: Windows Search started ignoring the Return key after I changed these settings. A machine restart fixed that. See @r33int's post below for other possible side-effects of this workaround._

_EDIT 2: @NicoVogel found that Search works better leaving InputServiceEnabledForCCI at 1._

I was clued to these registry values by watching Terminal in procmon. Terminal was repeatedly opening that key and querying one of those values. The queries possibly were correlated to keystrokes, but I can't say for sure.

@DHowett-MSFT , do you want diags from me as well? My case might be a different problem, since most of the people in this thread report keyboard problems in Search and other apps.

I had a version of this problem on a fresh install of Windows 19041.207 from ISO. It affected _only_ Windows Terminal; Search and other modern apps worked fine. I was able to resolve it by setting the following registry values and relaunching Terminal.

HKLM\SOFTWARE\Microsoft\Input:
  InputServiceEnabled: 0
  InputServiceEnabledForCCI: 0

I was clued to these registry values by watching Terminal in procmon. Terminal was repeatedly opening that key and querying one of those values. The queries possibly were correlated to keystrokes, but I can't say for sure.

@DHowett-MSFT , do you want diags from me as well? My case might be a different problem, since most of the people in this thread report keyboard problems in Search and other apps.

I can confirm this workaround works for me!
EDIT: This seems to cause some quirky behavior, such as special characters typing twice, and Search also stops working properly.

I'd like to take diags, but my privacy settings do not allow this, and I am not able to change them for some reason, I'm sorry...

@sharpjs That's really interesting. Traces from your repro might still be helpful, if I can note to the team your finding. :smile:

@DHowett-MSFT Finally I was able to change my privacy settings and take traces. I took two traces, one with @sharpjs workaround, and one without. Hope you can get something useful out of it.

https://plik.root.gg/file/HbRDChcSgYrb7DTD/Kec5YDDfRDjgnFoi/with%20workaround.zip

https://plik.root.gg/file/HbRDChcSgYrb7DTD/HyEEjVclBdGHiu3z/without%20workaround.zip

@r33int thanks! And just to confirm: In the "without workaround" case, you can't type into Terminal at all?

@r33int thanks! And just to confirm: In the "without workaround" case, you can't type into Terminal at all?

Yep

@r33int, or anybody else:

When you're in this state (no input), can you open up the clipboard history prompt (Windows+V) and seeing if your input magically starts working?

@r33int, or anybody else:

When you're in this state (no input), can you open up the clipboard history prompt (Windows+V) and seeing if your input magically starts working?

I have tried entering the clipboard history, and it does not seem to make the input work for me.

@DHowett-MSFT:

Traces from your repro might still be helpful,

• problem.diagnostics.zip
  
  
  
  • InputServiceEnabled{|ForCCI} = 1
  
  
  • Terminal seems to ignore keyboard input.
  
  
• workaround.diagnostics.zip
  
  
  
  • InputServiceEnabled{|ForCCI} = 0
  
  
  • Keyboard input to Terminal works normally.
  
  

can you open up the clipboard history prompt (Windows+V) and seeing if your input magically starts working?

Pressing Windows+V opens clipboard history, but does not cause keyboard input to start working.

@r33int:

This seems to cause some quirky behavior, such as special characters typing twice, and Search also stops working properly.

When I set InputServiceEnabled{|ForCCI} = 0, then the Return key specifically became ignored in Search. A machine restart fixed that for me.

I did not notice any problems typing special characters in Terminal or Search, but I use WinCompose, which might be different than your input method.

I'm curious- If you actually submit something through clipboard history, does it then start to work? You'll get a stray ^V or a paste (depending on how Terminal's set up), but a couple of my peers have theorized that this may help.

@DHowett-MSFT As for me:

1. Launch Terminal. ✔️
2. Win+V → clipboard history widget appears. ✔️
3. Click on a history item → nothing happens in terminal. ❌
4. Press a key → nothing happens in terminal. ❌
5. Right-click in Terminal → history item pastes into terminal. ✔️
6. Press a key → nothing happens in terminal. ❌

Diagnostics from steps 1-4: clipboard-history.diagnostics.zip

Clipboard history, generated by copying in Notepad:

Thanks! That's comprehensive :smile: and really helpful.

+1

@asolopovas Given that we've put together a detailed explanation of how you can help us, I'd appreciate it if you could help us gather more information on this bug instead of just sending "+1" comments.

@asolopovas Given that we've put together a detailed explanation of how you can help us, I'd appreciate it if you could help us gather more information on this bug instead of just sending "+1" comments.

i am expiriencing exactly same problem that @sharpjs shouldI be producing same report that he did?
@DHowett-MSFT or should I do something else to help?

That would be really helpful :smile: The more data we have on this bug, the better we can find correlations.

https://aka.ms/AA8b6o6

i can confirm the workaround below works for my issue:

https://github.com/microsoft/terminal/issues/4448#issuecomment-617290424

just changing InputServiceEnabled to a 0 worked for me, if thats any help

InputServiceEnabledForCCI is 1 (default)

if InputServiceEnabledForCCI is 0 and InputServiceEnabled is 1, it does NOT work

toggling InputServiceEnabled without restarting terminal allows terminal to accept input

Note that v1 fixed this issue for me, even after reversing the settings back to 1 for both

I mean, we didn’t change _anything_ so I’m going to say the intermittent nature of this bug made it seem fixed. :)

well, i lied. i deleted my settings, then restarted terminal and it does not work any more. set it back to 0 =(

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

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

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.

@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.

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)

@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

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.

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!

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.

@LuisMontoya1404

I need help!

Have you tried the workaround posted above? link

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.

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.

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.

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?

YES!!!

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

confirming reverting InputServiceEnabled to 1 fixes tabbing

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

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.

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

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.

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.

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.

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.

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

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.

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 _InputAppTextInputHost.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?

its ridiculous that this is still happening

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. :)

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.

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.

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?

@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.

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.

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.

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.

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

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.

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?

my service was DISABLED as well.

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

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

OK, after a reboot, IT WORKS.

The world makes sense again!

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.

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

b

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.

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...

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

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

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.

_guys there was a ";)", he's being facetious_

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!

Alright so it does sounds like there's a pretty strong correlation between this issue and the Touch/Handwriting service being disabled. For anyone else who's still encountering this, can you input text in _any_ UWP applications? I'm thinking following apps would be all be good tests:

• Feedback Hub
• Calculator
• the PowerToys Settings app
• the Microsoft Store
• the Your Phone app

We just want to make sure to do the diligence on our end to understand this issue fully. Thanks!

Changing the Service "_Touch Keyboard and Handwriting Panel_" from automatic to manual also solved the problem for me. Just to be sure, I also reset the Registry values back _(see below)_. I applied both changes before restarting and after it worked just fine.

HKLM\SOFTWARE\Microsoft\Input:
  InputServiceEnabled: 1
  InputServiceEnabledForCCI: 1

For context: I have a Surface pro 6 and validated (just in case), that my pen is still working. It all seems to work just fine.
Even all the wired behavior I described in my last post is gone.

@zadjii-msft regarding you question.
I quickly tested the following apps and had no issues with the input.

• Feedback Hub
• Calculator
• Microsoft Store

I confirm that I was able to prevent the bug by

• setting TabletInputService (Touch Keyboard and Handwriting Panel Service) from Disabled to Manual;
• setting HKLM\SOFTWARE\Microsoft\Input values back to their prior values (above); and,
• rebooting.

Now I have yet another seeminly unnecessary service running, but Terminal is working. 🎉

Off-topic: I'd pay good money for a first-party way to slim down Windows to just the bare essentials, then add things back as needed, with ultra-fine granularity. Call it Windows 10 Modular. I used to run a 'workstationized' Windows Server for this purpose, but that's not possible these days, as I need to run a few things that are specific to non-Server Windows.

@zadjii-msft IIRC, the _only_ UWP application I had a problem with was Terminal. The others worked.

To quote what' we've heard from the Input team:

The [Touch Keyboard and Handwriting Panel Service] is vital for keyboard and text input in UWAs and for IME input in all apps.

_For the record_, the Terminal isn't a UWP application, it's a hybrid application, one that's a packaged Win32 desktop application that happens to use UWP XAML for it's UI stack. If the other pure UWP apps on your system are working, then I'd think that this might be something specific to hybrid apps. Hence why I'm asking folks to check the PowerToys Settings app as well - they're using a similar enough app model to us.

If that app works, then there's something different between us and them that's causing this interaction. Maybe it's our lack of using IDesktopWindowXamlSourceNative2::PreTranslateMessage?

I can confirm that I have this issue with Windows Terminal but not with Calculator.

(and yes, because I disabled the apparently poorly-named Touch Keyboard and Handwriting Panel Service, which should probably have a comma between Touch and Keyboard)

The same issue «No keyboard input» after install updates Windows KB4566782 and KB4569745 and restart PC.
Also I clear registry with CCleaner 5.70.7909 and Auslogics BoostSpeed 9.2.0.0

Input via osk.exe also don't work.

But i can paste text from clipboard with right mouse click.

I try update winget install --id=Microsoft.WindowsTerminal -e and the same problems!

All ok after enable service Touch Keyboard and Handwriting Panel Service (Служба сенсорной клавиатуры и панели рукописного ввода) and reboot.

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?

You saved me the day. Thanks a lot!

To quote what' we've heard from the Input team:

The [Touch Keyboard and Handwriting Panel Service] is vital for keyboard and text input in UWAs and for IME input in all apps.

_For the record_, the Terminal isn't a UWP application, it's a hybrid application, one that's a packaged Win32 desktop application that happens to use UWP XAML for it's UI stack. If the other pure UWP apps on your system are working, then I'd think that this might be something specific to hybrid apps. Hence why I'm asking folks to check the PowerToys Settings app as well - they're using a similar enough app model to us.

I had this issue, and of course after setting Touch Keyboard and Handwriting Panel Service to Manual now input works. I can confirm Powertoys Settings app ALSO had the same issue. After the change, works too.

If that app works, then there's something different between us and them that's causing this interaction. Maybe it's our lack of using IDesktopWindowXamlSourceNative2::PreTranslateMessage?

Alright so it does sounds like there's a pretty strong correlation between this issue and the Touch/Handwriting service being disabled. For anyone else who's still encountering this, can you input text in any UWP applications? I'm thinking following apps would be all be good tests:

I found this issue while debugging a malfunctioning Windows Terminal. Your diagnosis is correct -- it happened because I'd disabled the handwriting service. My laptop doesn't have a touch-screen, and I didn't expect it to be useful.

Unfortunately I didn't disable it just to 'clean up Windows', but because it was killing battery life. For whatever reason, textinputhost.exe regularly starts running on the dGPU -- it doesn't draw to the screen at all, why does it need a GPU? -- and, in so doing, more than halves battery life.

I'm not sure where to report a bug such as this. Disabling the service is, however, common advice for fixing battery life problems.

(I get the impression that GPU choice is tuned assuming that the iGPU is weak and incapable, which may be true for Intel CPUs, but this is an AMD laptop.)

pinging @zadjii-msft in case didn't see my reply, Confirmed Powertoys Settings has same issue.

I have a surface 7 pro, and i've never disable handwriting services or any touch screen or pen input services. my terminal is no longer experiencing this issue at the moment though.

@jmlucjav I've forwarded that info along to the input team, thanks!

I confirm that I was able to prevent the bug by

• setting TabletInputService (Touch Keyboard and Handwriting Panel Service) from Disabled to Manual;
• setting HKLM\SOFTWARE\Microsoft\Input values back to their prior values (above); and,
• rebooting.

Now I have yet another seeminly unnecessary service running, but Terminal is working. 🎉

Off-topic: I'd pay good money for a first-party way to slim down Windows to just the bare essentials, then add things back as needed, with ultra-fine granularity. Call it Windows 10 Modular. I used to run a 'workstationized' Windows Server for this purpose, but that's not possible these days, as I need to run a few things that are specific to non-Server Windows.

@zadjii-msft IIRC, the _only_ UWP application I had a problem with was Terminal. The others worked.

I can confirm enabling that service completely fixes the problem, without creating any other problem. Thanks a lot @sharpjs for that find!

Thanks a lot @sharpjs for that find!

Actually, it's @swax06 that found it, to whom I give thanks from the both of us!

Thanks for the solutions. (Glad to see they are still users out there trying to cut the Windows fat. I thought it was a dying breed. ;-) )

I confirm that I was able to prevent the bug by

• setting TabletInputService (Touch Keyboard and Handwriting Panel Service) from Disabled to Manual;
• setting HKLM\SOFTWARE\Microsoft\Input values back to their prior values (above); and,
• rebooting.

Now I have yet another seeminly unnecessary service running, but Terminal is working. 🎉

Off-topic: I'd pay good money for a first-party way to slim down Windows to just the bare essentials, then add things back as needed, with ultra-fine granularity. Call it Windows 10 Modular. I used to run a 'workstationized' Windows Server for this purpose, but that's not possible these days, as I need to run a few things that are specific to non-Server Windows.

@zadjii-msft IIRC, the _only_ UWP application I had a problem with was Terminal. The others worked.

Enabling that service completely solved the problem. Thank you

Off topic reply: If you mean debloated windows iso, there are some custom isos which are done by some developors. Ofc, they aren't %100 safe but I have been using GhostSpectre modded iso for over a year and I am really happy about it.

On my system(Win10 x64 19041.508) running MSI Afterburner 4.6.2 beta 2 disables input in Windows terminal. Closing this app resolves problem.

I confirm that I was able to prevent the bug by

• setting TabletInputService (Touch Keyboard and Handwriting Panel Service) from Disabled to Manual;
• setting HKLM\SOFTWARE\Microsoft\Input values back to their prior values (above); and,
• rebooting.

Now I have yet another seeminly unnecessary service running, but Terminal is working. 🎉
Off-topic: I'd pay good money for a first-party way to slim down Windows to just the bare essentials, then add things back as needed, with ultra-fine granularity. Call it Windows 10 Modular. I used to run a 'workstationized' Windows Server for this purpose, but that's not possible these days, as I need to run a few things that are specific to non-Server Windows.
@zadjii-msft IIRC, the _only_ UWP application I had a problem with was Terminal. The others worked.

I can confirm enabling that service completely fixes the problem, without creating any other problem. Thanks a lot @sharpjs for that find!

On a side note, this also seems to fix the emoji panel showing up but not working issue!

Working solution on _Windows 10 2004 (OS build19041.508)_

In order to enable input I make next changes
FROM THIS (in my case it was _default setup and it did not work_):

HKLM\SOFTWARE\Microsoft\Input:
  InputServiceEnabled: 1
  InputServiceEnabledForCCI: 1

TO THIS (_works just fine_):

HKLM\SOFTWARE\Microsoft\Input:
  InputServiceEnabled: 0
  InputServiceEnabledForCCI: 1

Restart your machine, and you are ready to go!

No, in order to make your system work you must enable the service that everyone is talking about. Recommending that people set InputServiceEnabled to 0 in the registry is dangerous.

But it was a default setup, and it did not work, let me try once again.

After I reloaded my PC, it does not work.

What is the status of the touch keyboard and handwriting service?

Startup type is set to "Disabled"

Set it to something other than disabled. That is what the last 15 comments on this thread are about.

Yeah, Sorry about it 😞.

Thank you so much for this. Should I delete my comments?

I will handle cleanup. Thank you!

On my system(Win10 x64 19041.508) running MSI Afterburner 4.6.2 beta 2 disables input in Windows terminal. Closing this app resolves problem.

Same here

Unable to write inputs in integrated terminal vscode on manjaro

@LoboTormenta This is not the repository for VSCode _or_ Manjaro. Even though it has "Terminal" in the name, it is _not_ the catch-all repository for filing issues on terminals in general.

Since this thread has run its course and has a known root cause, and people have taken to driving by to say unkind things to/about us (hi @benfavre, thank you for deleting your comment), I'm going to lock this thread.

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.