No keyboard input #6263

@zadjii-msft commented on GitHub (Feb 3, 2020):

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?

@zadjii-msft commented on GitHub (Feb 3, 2020): 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?

claunia commented

@privacyguy123 commented on GitHub (Feb 3, 2020):

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?

@privacyguy123 commented on GitHub (Feb 3, 2020): 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?

claunia commented

@privacyguy123 commented on GitHub (Feb 6, 2020):

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?

@privacyguy123 commented on GitHub (Feb 6, 2020): 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?

claunia commented

@privacyguy123 commented on GitHub (Feb 7, 2020):

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

@privacyguy123 commented on GitHub (Feb 7, 2020): Bumping this. I see a blinking cursor but still unable to type in Windows Terminal.

claunia commented

@MCrank commented on GitHub (Feb 12, 2020):

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.

@MCrank commented on GitHub (Feb 12, 2020): 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 ![image](https://user-images.githubusercontent.com/3493649/74351197-6c828d00-4d7c-11ea-9109-b412ef2aacde.png) 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.

claunia commented

@JoshuaJarman commented on GitHub (Feb 12, 2020):

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?

@JoshuaJarman commented on GitHub (Feb 12, 2020): 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?

claunia commented

@DHowett-MSFT commented on GitHub (Feb 24, 2020):

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 commented on GitHub (Feb 24, 2020): 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.

claunia commented

@simmessa commented on GitHub (Mar 2, 2020):

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

@simmessa commented on GitHub (Mar 2, 2020): @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.

claunia commented

@JoshuaJarman commented on GitHub (Mar 4, 2020):

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

@JoshuaJarman commented on GitHub (Mar 4, 2020): 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

claunia commented

@feokuma commented on GitHub (Mar 5, 2020):

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.

@feokuma commented on GitHub (Mar 5, 2020): > 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.

claunia commented

@bampo commented on GitHub (Mar 5, 2020):

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)

@bampo commented on GitHub (Mar 5, 2020): 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)

claunia commented

@keithnyc commented on GitHub (Mar 5, 2020):

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

@keithnyc commented on GitHub (Mar 5, 2020): 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

claunia commented

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

@YihaoPeng commented on GitHub (Mar 6, 2020):

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:

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.

@YihaoPeng commented on GitHub (Mar 6, 2020): 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.

claunia commented

@keithnyc commented on GitHub (Mar 7, 2020):

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

@keithnyc commented on GitHub (Mar 7, 2020): Windows Insider build 19577 seems to have fixed this issue for me (yay!)

claunia commented

@dai commented on GitHub (Mar 13, 2020):

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 キー)

@dai commented on GitHub (Mar 13, 2020): > 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 キー)

claunia commented

@DHowett-MSFT commented on GitHub (Mar 18, 2020):

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.

@DHowett-MSFT commented on GitHub (Mar 18, 2020): 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.

claunia commented

@DHowett-MSFT commented on GitHub (Mar 18, 2020):

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.

@DHowett-MSFT commented on GitHub (Mar 18, 2020): 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.

claunia commented

@dai commented on GitHub (Mar 18, 2020):

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

@dai commented on GitHub (Mar 18, 2020): 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

claunia commented

@zanardob commented on GitHub (Mar 24, 2020):

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

@zanardob commented on GitHub (Mar 24, 2020): 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

claunia commented

@densuke commented on GitHub (Mar 25, 2020):

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

@densuke commented on GitHub (Mar 25, 2020): 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

claunia commented

@shashankholla commented on GitHub (Mar 28, 2020):

Yes, I seem to have the issue as well.

Windows Version 10.0.19587 Build 19587
WT 0.10.781.0
English(US)

@shashankholla commented on GitHub (Mar 28, 2020): Yes, I seem to have the issue as well. - Windows Version 10.0.19587 Build 19587 - WT 0.10.781.0 - English(US)

claunia commented

@r33int commented on GitHub (Apr 9, 2020):

Can also confirm this issue.

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

@r33int commented on GitHub (Apr 9, 2020): Can also confirm this issue. - Microsoft Windows [version 10.0.19041.153] - Terminal v0.10.781.0 - French (FR)

claunia commented

@DesigningKnights commented on GitHub (Apr 14, 2020):

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.

@DesigningKnights commented on GitHub (Apr 14, 2020): 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.

claunia commented

@DesigningKnights commented on GitHub (Apr 16, 2020):

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.

@DesigningKnights commented on GitHub (Apr 16, 2020): 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.

claunia commented

@simmessa commented on GitHub (Apr 17, 2020):

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

@simmessa commented on GitHub (Apr 17, 2020): I'm on 19592 and I haven't seen this happen in a while. Feeling lucky :)

claunia commented

@akulbe commented on GitHub (Apr 20, 2020):

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

@akulbe commented on GitHub (Apr 20, 2020): I am on the latest Slow Ring (19041.207) and I see this as well.

claunia commented

@DHowett-MSFT commented on GitHub (Apr 21, 2020):

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.

@DHowett-MSFT commented on GitHub (Apr 21, 2020): 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? ![image](https://user-images.githubusercontent.com/14316954/79807649-67176500-8320-11ea-85ba-05dac47c034f.png) ![image](https://user-images.githubusercontent.com/14316954/79807653-6aaaec00-8320-11ea-960c-eda0c5b1baf1.png) 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: ![image](https://user-images.githubusercontent.com/14316954/79807702-8f06c880-8320-11ea-879a-daa9140d759b.png) 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.

claunia commented

@DHowett-MSFT commented on GitHub (Apr 21, 2020):

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 😄

@DHowett-MSFT commented on GitHub (Apr 21, 2020): 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:

claunia commented

@sharpjs commented on GitHub (Apr 21, 2020):

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.

@sharpjs commented on GitHub (Apr 21, 2020): 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. ```yaml 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](https://github.com/microsoft/terminal/issues/4448#issuecomment-645376971) 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.

claunia commented

@r33int commented on GitHub (Apr 21, 2020):

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

@r33int commented on GitHub (Apr 21, 2020): > 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. > > ```yaml > 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...

claunia commented

@DHowett-MSFT commented on GitHub (Apr 21, 2020):

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

@DHowett-MSFT commented on GitHub (Apr 21, 2020): @sharpjs That's really interesting. Traces from your repro might still be helpful, if I can note to the team your finding. :smile:

claunia commented

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

@r33int commented on GitHub (Apr 21, 2020):

@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/HyEEjVclBdGHiu3z/without%20workaround.zip

@r33int commented on GitHub (Apr 21, 2020): @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

claunia commented

@DHowett-MSFT commented on GitHub (Apr 21, 2020):

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

@DHowett-MSFT commented on GitHub (Apr 21, 2020): @r33int thanks! And just to confirm: In the "without workaround" case, you can't type into Terminal at all?

claunia commented

@r33int commented on GitHub (Apr 21, 2020):

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

Yep

@r33int commented on GitHub (Apr 21, 2020): > @r33int thanks! And just to confirm: In the "without workaround" case, you can't type into Terminal at all? Yep

claunia commented

@DHowett-MSFT commented on GitHub (Apr 21, 2020):

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

@DHowett-MSFT commented on GitHub (Apr 21, 2020): @r33int, or anybody else: When you're in this state (no input), can you open up the clipboard history prompt (<kbd>Windows+V</kbd>) and seeing if your input magically starts working?

claunia commented

@r33int commented on GitHub (Apr 21, 2020):

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

@r33int commented on GitHub (Apr 21, 2020): > @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.

claunia commented

@sharpjs commented on GitHub (Apr 23, 2020):

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

@sharpjs commented on GitHub (Apr 23, 2020): @DHowett-MSFT: > Traces from your repro might still be helpful, - [problem.diagnostics.zip](https://github.com/microsoft/terminal/files/4522952/problem.diagnostics.zip) - `InputServiceEnabled{|ForCCI} = 1` - Terminal seems to ignore keyboard input. - [workaround.diagnostics.zip](https://github.com/microsoft/terminal/files/4522954/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.

claunia commented

@DHowett-MSFT commented on GitHub (Apr 24, 2020):

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 commented on GitHub (Apr 24, 2020): 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.

claunia commented

@sharpjs commented on GitHub (Apr 24, 2020):

@DHowett-MSFT As for me:

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

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

Clipboard history, generated by copying in Notepad:

@sharpjs commented on GitHub (Apr 24, 2020): @DHowett-MSFT As for me: 1. Launch Terminal. ✔️ 1. `Win+V` → clipboard history widget appears. ✔️ 1. Click on a history item → nothing happens in terminal. ❌ 1. Press a key → nothing happens in terminal. ❌ 1. Right-click in Terminal → history item pastes into terminal. ✔️ 1. Press a key → nothing happens in terminal. ❌ Diagnostics from steps 1-4: [clipboard-history.diagnostics.zip](https://github.com/microsoft/terminal/files/4531877/clipboard-history.diagnostics.zip) Clipboard history, generated by copying in Notepad: <img width="261" alt="Clipboard" src="https://user-images.githubusercontent.com/708461/80262614-d0f67e00-8642-11ea-8c3e-e69cd02478c5.png">

claunia commented

@DHowett-MSFT commented on GitHub (Apr 25, 2020):

Thanks! That's comprehensive 😄 and really helpful.

@DHowett-MSFT commented on GitHub (Apr 25, 2020): Thanks! That's comprehensive :smile: and really helpful.

claunia commented

@asolopovas commented on GitHub (Apr 28, 2020):

+1

@asolopovas commented on GitHub (Apr 28, 2020): +1

claunia commented

@DHowett-MSFT commented on GitHub (Apr 28, 2020):

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

@DHowett-MSFT commented on GitHub (Apr 28, 2020): @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.

claunia commented

@asolopovas commented on GitHub (Apr 29, 2020):

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

@asolopovas commented on GitHub (Apr 29, 2020): > @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?

claunia commented

@DHowett-MSFT commented on GitHub (Apr 30, 2020):

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

@DHowett-MSFT commented on GitHub (Apr 30, 2020): That would be really helpful :smile: The more data we have on this bug, the better we can find correlations.

claunia commented

@asolopovas commented on GitHub (May 3, 2020):

https://aka.ms/AA8b6o6

@asolopovas commented on GitHub (May 3, 2020): https://aka.ms/AA8b6o6

claunia commented

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

@EricZimmerman commented on GitHub (May 15, 2020):

i can confirm the workaround below works for my issue:

@EricZimmerman commented on GitHub (May 15, 2020): i can confirm the workaround below works for my issue: https://github.com/microsoft/terminal/issues/4448#issuecomment-617290424

claunia commented

@EricZimmerman commented on GitHub (May 15, 2020):

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

@EricZimmerman commented on GitHub (May 15, 2020): 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

claunia commented

@EricZimmerman commented on GitHub (May 19, 2020):

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

@EricZimmerman commented on GitHub (May 19, 2020): Note that v1 fixed this issue for me, even after reversing the settings back to 1 for both

claunia commented

@DHowett commented on GitHub (May 19, 2020):

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

@DHowett commented on GitHub (May 19, 2020): I mean, we didn’t change _anything_ so I’m going to say the intermittent nature of this bug made it seem fixed. :)

claunia commented

@EricZimmerman commented on GitHub (May 19, 2020):

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

@EricZimmerman commented on GitHub (May 19, 2020): well, i lied. i deleted my settings, then restarted terminal and it does not work any more. set it back to 0 =(

claunia commented

@Kein commented on GitHub (May 26, 2020):

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

@Kein commented on GitHub (May 26, 2020): I have the same issue on 2004 test setup in VM. Workaround works but ¯\\\_(ツ)\_/¯

claunia commented

@ilkersigirci commented on GitHub (May 31, 2020):

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

@ilkersigirci commented on GitHub (May 31, 2020): In 2004, I am experiencing the same problem, workaround works though

claunia commented

2026-01-31 00:33:54 +00:00

@ghost commented on GitHub (Jun 1, 2020):

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.

@ghost commented on GitHub (Jun 1, 2020): 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.

claunia commented

@sharpjs commented on GitHub (Jun 1, 2020):

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

@sharpjs commented on GitHub (Jun 1, 2020): @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.

claunia commented

2026-01-31 00:33:54 +00:00

@jmartsch commented on GitHub (Jun 1, 2020):

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)

@jmartsch commented on GitHub (Jun 1, 2020): 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)

claunia commented

2026-01-31 00:33:54 +00:00

@ghost commented on GitHub (Jun 1, 2020):

@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 commented on GitHub (Jun 1, 2020): @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 ```

claunia commented

@ghost commented on GitHub (Jun 1, 2020):

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.

@ghost commented on GitHub (Jun 1, 2020): > 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` ![Annotation 2020-06-01 214347](https://user-images.githubusercontent.com/13611490/83447658-129ff300-a451-11ea-9bbf-15b973ddd5c1.png) Either the bug is in that app or WT has a problem communicating with it correctly.

claunia commented

@SupplelyBasil36 commented on GitHub (Jun 2, 2020):

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!

@SupplelyBasil36 commented on GitHub (Jun 2, 2020): 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!

claunia commented

@aaugmentum commented on GitHub (Jun 3, 2020):

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.

@aaugmentum commented on GitHub (Jun 3, 2020): 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.

claunia commented

@sharpjs commented on GitHub (Jun 3, 2020):

@LuisMontoya1404

I need help!

Have you tried the workaround posted above? link

@sharpjs commented on GitHub (Jun 3, 2020): @LuisMontoya1404 > I need help! Have you tried the workaround posted above? [link](https://github.com/microsoft/terminal/issues/4448#issuecomment-617290424)

claunia commented

@lisalander commented on GitHub (Jun 5, 2020):

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.

@lisalander commented on GitHub (Jun 5, 2020): 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.

claunia commented

@NicoVogel commented on GitHub (Jun 17, 2020):

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

The following inputs did not work: Delete, Backwards, Pos1, End, Arrow keys, Enter
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.

@NicoVogel commented on GitHub (Jun 17, 2020): I also have the same issue. - Windows version: 19041.329 - Windows Terminal version: 1.0.1401.0 The [workaround](https://github.com/microsoft/terminal/issues/4448#issuecomment-617290424) 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](https://github.com/microsoft/terminal/issues/4448#issuecomment-636939724)). 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](https://github.com/microsoft/terminal/issues/4448#issuecomment-617290424) 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*.

claunia commented

@kvaranovich commented on GitHub (Jun 20, 2020):

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.

@kvaranovich commented on GitHub (Jun 20, 2020): 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.

claunia commented

@r33int commented on GitHub (Jun 23, 2020):

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?

@r33int commented on GitHub (Jun 23, 2020): 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? ![ezgif com-video-to-gif](https://user-images.githubusercontent.com/22567851/85414295-32b46500-b56c-11ea-9cda-1adb66d500a0.gif)

claunia commented

@EricZimmerman commented on GitHub (Jun 23, 2020):

YES!!!

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

@EricZimmerman commented on GitHub (Jun 23, 2020): YES!!! I have been trying to figure out why terminal has been double tapping like that for a long time! Great find

claunia commented

@EricZimmerman commented on GitHub (Jun 23, 2020):

confirming reverting InputServiceEnabled to 1 fixes tabbing

@EricZimmerman commented on GitHub (Jun 23, 2020): confirming reverting InputServiceEnabled to 1 fixes tabbing

claunia commented

@NicoVogel commented on GitHub (Jun 23, 2020):

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

@NicoVogel commented on GitHub (Jun 23, 2020): > 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

claunia commented

@EricZimmerman commented on GitHub (Jun 23, 2020):

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.

@EricZimmerman commented on GitHub (Jun 23, 2020): 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.

claunia commented

@rafavielma commented on GitHub (Jun 28, 2020):

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

@rafavielma commented on GitHub (Jun 28, 2020): keyboard doesn't work happens to someone else, the solution they give disables win + v and other functions

claunia commented

@julianonunes commented on GitHub (Jun 29, 2020):

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.

@julianonunes commented on GitHub (Jun 29, 2020): > 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 ](https://github.com/microsoft/terminal/issues/4448#issuecomment-617290424) solved it without breaking hotkeys like win + v.

claunia commented

@rafavielma commented on GitHub (Jun 29, 2020):

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.

@rafavielma commented on GitHub (Jun 29, 2020): > > 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 ](https://github.com/microsoft/terminal/issues/4448#issuecomment-617290424) solved it without breaking hotkeys like win + v. InputServiceEnabled = 0 but that causes the search window not accepting ENTER from the keyboard.

claunia commented

@julianonunes commented on GitHub (Jun 29, 2020):

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.

@julianonunes commented on GitHub (Jun 29, 2020): > > > 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 ](https://github.com/microsoft/terminal/issues/4448#issuecomment-617290424) 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.

claunia commented

@rafavielma commented on GitHub (Jun 30, 2020):

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 commented on GitHub (Jun 30, 2020): > > > > 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 ](https://github.com/microsoft/terminal/issues/4448#issuecomment-617290424) 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.

claunia commented

@sharpjs commented on GitHub (Jun 30, 2020):

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

@sharpjs commented on GitHub (Jun 30, 2020): @rafavielma @julianonunes You need to restart after applying the workaround. See [the table](https://github.com/microsoft/terminal/issues/4448#issuecomment-645376971) that @NicoVogel made.

claunia commented

@DessertArbiter commented on GitHub (Jun 30, 2020):

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.

@DessertArbiter commented on GitHub (Jun 30, 2020): 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.

claunia commented

@ghost commented on GitHub (Jul 1, 2020):

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?

@ghost commented on GitHub (Jul 1, 2020): 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?

claunia commented

@EricZimmerman commented on GitHub (Jul 1, 2020):

its ridiculous that this is still happening

@EricZimmerman commented on GitHub (Jul 1, 2020): its ridiculous that this is still happening

claunia commented

2026-01-31 00:34:00 +00:00

@ghost commented on GitHub (Jul 1, 2020):

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

@ghost commented on GitHub (Jul 1, 2020): 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. :)

claunia commented

@DHowett commented on GitHub (Jul 1, 2020):

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.

@DHowett commented on GitHub (Jul 1, 2020): 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.

claunia commented

2026-01-31 00:34:00 +00:00

@zadjii-msft commented on GitHub (Aug 14, 2020):

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.

@zadjii-msft commented on GitHub (Aug 14, 2020): 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.

claunia commented

2026-01-31 00:34:00 +00:00

@ghost commented on GitHub (Aug 14, 2020):

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?

@ghost commented on GitHub (Aug 14, 2020): > 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?

claunia commented

2026-01-31 00:34:01 +00:00

@sharpjs commented on GitHub (Aug 15, 2020):

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

@sharpjs commented on GitHub (Aug 15, 2020): @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.

claunia commented

2026-01-31 00:34:01 +00:00

@ghost commented on GitHub (Aug 18, 2020):

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.

@ghost commented on GitHub (Aug 18, 2020): 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.

claunia commented

2026-01-31 00:34:01 +00:00

@nickpage221 commented on GitHub (Aug 18, 2020):

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.

@nickpage221 commented on GitHub (Aug 18, 2020): > 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.

claunia commented

@ghost commented on GitHub (Aug 18, 2020):

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.

@ghost commented on GitHub (Aug 18, 2020): 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.

claunia commented

@johnhauhnar commented on GitHub (Aug 19, 2020):

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

@johnhauhnar commented on GitHub (Aug 19, 2020): 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

claunia commented

@swax06 commented on GitHub (Aug 19, 2020):

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.

@swax06 commented on GitHub (Aug 19, 2020): 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.

claunia commented

@NightWulfe commented on GitHub (Aug 19, 2020):

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?

@NightWulfe commented on GitHub (Aug 19, 2020): **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?

claunia commented

@EricZimmerman commented on GitHub (Aug 19, 2020):

my service was DISABLED as well.

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

@EricZimmerman commented on GitHub (Aug 19, 2020): my service was DISABLED as well. i set it to manual and will reboot to see how it goes

claunia commented

@gfxonline commented on GitHub (Aug 19, 2020):

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

@gfxonline commented on GitHub (Aug 19, 2020): 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

claunia commented

@EricZimmerman commented on GitHub (Aug 19, 2020):

OK, after a reboot, IT WORKS.

The world makes sense again!

@EricZimmerman commented on GitHub (Aug 19, 2020): OK, after a reboot, IT WORKS. The world makes sense again!

claunia commented

@DHowett commented on GitHub (Aug 19, 2020):

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.

@DHowett commented on GitHub (Aug 19, 2020): 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.

claunia commented

@BobGallardo commented on GitHub (Aug 19, 2020):

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

b

@BobGallardo commented on GitHub (Aug 19, 2020): Same here. TabletInputService was disabled. Setting the startup type to manual has resolved the issue for me. Nice find! b

claunia commented

@gfxonline commented on GitHub (Aug 19, 2020):

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.

@gfxonline commented on GitHub (Aug 19, 2020): > 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.

claunia commented

@ghost commented on GitHub (Aug 19, 2020):

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

@ghost commented on GitHub (Aug 19, 2020): > 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...

claunia commented

@BobGallardo commented on GitHub (Aug 19, 2020):

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

@BobGallardo commented on GitHub (Aug 19, 2020): 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

claunia commented

@EricZimmerman commented on GitHub (Aug 19, 2020):

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

@EricZimmerman commented on GitHub (Aug 19, 2020): what @gfxonline said. i am on a workstation with no touch anything. seemed unnecessary, but what do i know?

claunia commented

@NightWulfe commented on GitHub (Aug 19, 2020):

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.

@NightWulfe commented on GitHub (Aug 19, 2020): > 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.

claunia commented

@zadjii-msft commented on GitHub (Aug 19, 2020):

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

@zadjii-msft commented on GitHub (Aug 19, 2020): _guys there was a ";)", he's being facetious_

claunia commented

@ghost commented on GitHub (Aug 19, 2020):

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!

@ghost commented on GitHub (Aug 19, 2020): 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!

claunia commented

@zadjii-msft commented on GitHub (Aug 19, 2020):

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!

@zadjii-msft commented on GitHub (Aug 19, 2020): 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!

claunia commented

@NicoVogel commented on GitHub (Aug 19, 2020):

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

@NicoVogel commented on GitHub (Aug 19, 2020): 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. ```yaml 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](https://github.com/microsoft/terminal/issues/4448#issuecomment-645376971) 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

claunia commented

@sharpjs commented on GitHub (Aug 19, 2020):

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.

@sharpjs commented on GitHub (Aug 19, 2020): 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.

claunia commented

@zadjii-msft commented on GitHub (Aug 19, 2020):

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?

@zadjii-msft commented on GitHub (Aug 19, 2020): 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`?

claunia commented

@adam-azarchs commented on GitHub (Aug 20, 2020):

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)

@adam-azarchs commented on GitHub (Aug 20, 2020): 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`)

claunia commented

@4n70w4 commented on GitHub (Aug 21, 2020):

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.

@4n70w4 commented on GitHub (Aug 21, 2020): 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.

claunia commented

2026-01-31 00:34:07 +00:00

@kemploe commented on GitHub (Aug 21, 2020):

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!

@kemploe commented on GitHub (Aug 21, 2020): > **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!

claunia commented

@jmlucjav commented on GitHub (Aug 22, 2020):

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?

@jmlucjav commented on GitHub (Aug 22, 2020): > 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`?

claunia commented

2026-01-31 00:34:07 +00:00

@Baughn commented on GitHub (Aug 25, 2020):

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

@Baughn commented on GitHub (Aug 25, 2020): > 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.)

claunia commented

2026-01-31 00:34:07 +00:00

@jmlucjav commented on GitHub (Aug 25, 2020):

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

@jmlucjav commented on GitHub (Aug 25, 2020): pinging @zadjii-msft in case didn't see my reply, Confirmed Powertoys Settings has same issue.

claunia commented

@JoshuaJarman commented on GitHub (Aug 25, 2020):

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.

@JoshuaJarman commented on GitHub (Aug 25, 2020): 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.

claunia commented

@zadjii-msft commented on GitHub (Aug 25, 2020):

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

@zadjii-msft commented on GitHub (Aug 25, 2020): @jmlucjav I've forwarded that info along to the input team, thanks!

claunia commented

@r33int commented on GitHub (Aug 29, 2020):

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!

@r33int commented on GitHub (Aug 29, 2020): > 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!

claunia commented

@sharpjs commented on GitHub (Aug 30, 2020):

Thanks a lot @sharpjs for that find!

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

@sharpjs commented on GitHub (Aug 30, 2020): > Thanks a lot @sharpjs for that find! Actually, it's @swax06 that found it, to whom I give thanks from the both of us!

claunia commented

2026-01-31 00:34:09 +00:00

@dienluong commented on GitHub (Aug 31, 2020):

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

@dienluong commented on GitHub (Aug 31, 2020): 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. ;-) )

claunia commented

@ilkersigirci commented on GitHub (Aug 31, 2020):

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.

@ilkersigirci commented on GitHub (Aug 31, 2020): > 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.

claunia commented

2026-01-31 00:34:09 +00:00

@korotky commented on GitHub (Sep 9, 2020):

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.

@korotky commented on GitHub (Sep 9, 2020): 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.

claunia commented

2026-01-31 00:34:10 +00:00

@OlivierDoriath commented on GitHub (Sep 13, 2020):

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!

@OlivierDoriath commented on GitHub (Sep 13, 2020): > > 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!

claunia commented

2026-01-31 00:34:11 +00:00

@UtmostCreator commented on GitHub (Sep 22, 2020):

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!

@UtmostCreator commented on GitHub (Sep 22, 2020): 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!

claunia commented

2026-01-31 00:34:11 +00:00

@DHowett commented on GitHub (Sep 22, 2020):

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.

@DHowett commented on GitHub (Sep 22, 2020): 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.

claunia commented

2026-01-31 00:34:12 +00:00

@UtmostCreator commented on GitHub (Sep 22, 2020):

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

@UtmostCreator commented on GitHub (Sep 22, 2020): But it was a default setup, and it did not work, let me try once again.

claunia commented

2026-01-31 00:34:12 +00:00

@UtmostCreator commented on GitHub (Sep 22, 2020):

After I reloaded my PC, it does not work.

@UtmostCreator commented on GitHub (Sep 22, 2020): After I reloaded my PC, it does not work. ![image](https://user-images.githubusercontent.com/22347676/93922031-0f8b8400-fd1a-11ea-99f8-5cda5822c1b0.png)

claunia commented

2026-01-31 00:34:12 +00:00

@DHowett commented on GitHub (Sep 22, 2020):

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

@DHowett commented on GitHub (Sep 22, 2020): What is the status of the touch keyboard and handwriting service?

claunia commented

2026-01-31 00:34:13 +00:00

@UtmostCreator commented on GitHub (Sep 22, 2020):

Startup type is set to "Disabled"

@UtmostCreator commented on GitHub (Sep 22, 2020): Startup type is set to "Disabled"

claunia commented

2026-01-31 00:34:13 +00:00

@DHowett commented on GitHub (Sep 22, 2020):

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

@DHowett commented on GitHub (Sep 22, 2020): Set it to something other than disabled. That is what the last 15 comments on this thread are about.

claunia commented

2026-01-31 00:34:14 +00:00

@UtmostCreator commented on GitHub (Sep 22, 2020):

Yeah, Sorry about it 😞.

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

@UtmostCreator commented on GitHub (Sep 22, 2020): Yeah, Sorry about it 😞. Thank you so much for this. Should I delete my comments?

claunia commented

@DHowett commented on GitHub (Sep 22, 2020):

I will handle cleanup. Thank you!

@DHowett commented on GitHub (Sep 22, 2020): I will handle cleanup. Thank you!

claunia commented

@benfavre commented on GitHub (Oct 10, 2020):

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

@benfavre commented on GitHub (Oct 10, 2020): > 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

claunia commented

@LoboTormenta commented on GitHub (Oct 11, 2020):

Unable to write inputs in integrated terminal vscode on manjaro

@LoboTormenta commented on GitHub (Oct 11, 2020): Unable to write inputs in integrated terminal vscode on manjaro

claunia commented