terminal
terminal copied to clipboard
One letter types twice
Windows Terminal version
1.11.2921.0
Windows build number
10.0.19044.0
Other Software
powershell 5.1 (build 19041 revision 1320) mongosh 1.0.5 (I don't think that it's matter)
Steps to reproduce
- Open new tab
- Turn on something and wait for hour (i didn't anything else)
- Type something (e.x. "cls")
Expected Behavior
I see "cls"
Actual Behavior
I see "ccllss"
P.S. my keyboard is good, in other programs I don't get this result
You know, I feel like we've seen this before but I can't seem to find a dupe...
Does this only happen when you're running mongosh? Does this occur in just a plain powershell tab, or even a Command Prompt tab?
What keyboard layout are you using? Are you possibly switching between keyboard layouts?
You might be able to run the Terminal with a debug tap to get a trace of all the input and output. Once the bug starts occuring, send us a screenshot and we might be able to figure out what the Terminal thinks it's getting here.
Does this only happen when you're running mongosh?
No, not only. Once I've just oppened new powershell tab and this bug repeated
Does this occur in just a plain powershell tab, or even a Command Prompt tab?
I haven't tested with other shells yet, so I don't know
What keyboard layout are you using? Are you possibly switching between keyboard layouts?
I use Russian standart layout (йцукен) and English (I think USA) (qwerty). I can switch them, in both layouts letters are doubling
Okay yea, a debug tap trace is the next best thing to try. Maybe that'll give us a hint.
This problem didn't appear again for a month (maybe some of Windows updates affected this), but if you need debug tap:
␛[?9001h␛[2J␛[m␛[HWindows␣PowerShell␍␊(C)␣Корпорация␣Майкрософт␣(Microsoft␣Corporation).␣Все␣права␣защищены.␛[4;1HПопробуйте␣новую␣кроссплатформенную␣оболочку␣PowerShell␣(https://aka.ms/pscore6)␛]0;Windows␣PowerShell␇␛[?25h␛[?25l␛[7;1H␛[?25h␛[?25l␛[H␛[?25h␛[?25l␛[3J␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␛[H␛[?25h␛[?25l␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␍␊␛[K␛[H␛[?25hPS␣Z:\>␣
This problem didn't appear again for a month
Ah, so okay, if it's not really happening anymore, then there's not much else we can do here 🤷 If it does start repro'ing consistently, then open up a new tab with the debug tap, use it like you would normally, and once it starts to repro, then copy-paste the content. We can re-open this then. Thanks!
Happened to me yesterday. Enabled the debug tap mentioned in other post, opened a wsl tab and today got the same character doubling behabiour. This is a screenshot:

The keys in that screenshot look normal - a down and an up for each.
Did this work before (and regress recently)? Is there anything else about your system that might have changed?
I suppose it's possible that there's some uninitialized memory that could trigger this, maybe.
Does this repro with cmd, pwsh? Or just bash in WSL?
The keys in that screenshot look normal - a down and an up for each.
Did this work before (and regress recently)? Is there anything else about your system that might have changed?
In general, i have only experienced this issue recently, and always on tabs that have been open for a significant time.
In the case of the screenshot posted yesterday, a couple other tabs on the same wt window were affected by the issue but the other (fresh from the day) were not. Then, proceeded to set up the debug tap , open a new tab and leave it open (locking the session, with Win+L). This was on 2022-11-15 and while working on the pc directly.
Yesterday (2022 -11-16) connected to it though RDP (mstsc /v pchostname) and when i went to use it, it showed the same problem and it was then when i took that screenshot.
I suppose it's possible that there's some uninitialized memory that could trigger this, maybe.
🤷♂️ Don't know. But there's one thing, it seems to be tab-local, i mean: there can be open tabs that are affected and others that are unaffected at the same time, side by side in the same wt window.
Also, once a tab starts to be affected by the issue, it seems to be affected until it is closed, it seems kinda permanent.
Yet another thing; don't know if it might be relevant, but after typing anything, it seems possible to delete characters one by one (Maybe keypresses from input that maps to control characters are not duplicated? 🤔)
Does this repro with cmd, pwsh? Or just
bashin WSL?
Today (2022-11-17), physically on the pc, and in the very same tab of the previous screenshot (launching cmd.exe from the wsl shell):

(spammed the <Delete/Backspace> key and pressed <Enter> several times before screenshot)
Does not seem to care what it is running underneath, but i'll try to test it on a new tab for cmd/pwsh.
This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.
Sorry about the overactive bot!
oh hey we missed something! The input records are wrong, we've got both a character AND an INPUT_RECORD, which isn't what you want!

Maybe the Russian keyboard layout thing really matters here! IIRC this was noticed once before in an IME, but idk if it was in russian necessarily
This seems to have started after I opened the terminal from a read-only file. I am facing the same issue too.
I hit this today. New tabs after turning on debugtap didn't repro. This happened in both a cmd and WSL tab.
This was on full English setup. Running Preview v1.18.902.0. The only weird things:
- I may have taken an update to Terminal from Store when this started; exact timeline is unclear
- New instance of terminal are throwing on launch which makes me think more I'm in some screwed up halfway updated state
- On the taskbar I have a suspicious extra window called
DesktopWindowXamlSourcein the Terminal group (below)

I can reproduce this today. I do have an extra unusual keymap, but it happens with vanilla English UK and Japanese.
Windows 10 22H2, Terminal 1.16.10261.0. I'm experiencing this with a standard US keyboard layout and have been dealing with it intermittently for the past year+. It seems to start happening after I initiate a Remote Desktop session into my machine and continues until a given Terminal tab is closed, even when I subsequently log into the machine locally. (The Remote Desktop aspect might be a red herring; I'm not sure.)
Newly-started tabs are unaffected; I can switch from new to old and get doubled characters, and then switch back to new and type normally. Backspace, ^C, newlines, etc. seem unaffected; letters, numbers, and spaces are affected. I have a debug tap open on a new tab and will edit this comment with the results once that tab starts experiencing the issue.
oh hey we missed something! The input records are wrong, we've got both a character AND an INPUT_RECORD, which isn't what you want!
@zadjii-msft I don't think there's anything wrong with that. What you're seeing is the key down and key up events. This is exactly what I get for a single keypress of q.
␛[81;16;113;1;32;1_␛[81;16;113;0;32;1_q
Virtual-key code for the Q key is 81.
Scan code for the Q key is 16.
ASCII value for q is 113.
Key down state is 1 then 0.
Control key state is 32 (NumLock on).
Repeat count is 1.
So it looks like we're sending the correct data through to conhost, but it might be the conhost translation of those records back into input events that is going wrong somewhere.
I wonder if it's possible for Windows Terminal and the connected conhost to end up with differing keyboard layouts, and whether that would have any weird side effects (e.g. WT is passing through a scan code for a US keyboard, but conhost thinks it's using some other layout). I can't imagine how that would trigger a repeated key though.
Doh! Disregard that. I completely missed the bright green square highlighting the first q passed though as a regular character!
Do you still need additional debug tap output?
Circling back to this one. We're going to mark this as a /dup of #15591 because the other one has more specific debugging notes in it (and a better title :P)
Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!
Left a note on the other issue about why I think these are different.
@zadjii-msft @carlos-zamora I concurr with @DHowett — these two issues don't seem to be related at all.
A couple of questions to narrow this input issue down:
- Do people encountering this issue use keyboards that have their own drivers (i.e. keyboards or mice with added functionality such as macro recording, faster polling rate, etc)?
- When you RDP into your PC and this double character input starts, does it still continue if you disconnect your RDP session (do not sign out, just click x on the connection bar), login on the PC directly, and use physical keyboard to type? Testing this would require physical presence and another device on the same network.
- When you RDP into your PC and this double character input starts, does it still continue if you type into Windows Terminal using on-screen keyboard instead of RDP or physical keyboard?
- Do you have any software on your PC which might have installed keyboard and/or mouse filter drivers?
- Do you have clipboard history enabled in Windows? How about clipboard cloud syncing?
@levicki
- No, boring keyboard and mouse. The keyboard uses a PS/2 to USB adapter, the mouse is just a mouse. I do have a USB KVM, but it doesn't require any drivers. That said, it does disconnect the devices when it toggles.
- Yes, it continues. (I'm able to provide this info as an unexpected benefit of having occasional 15-ish second connectivity drops between work and home.) 2a. If I open a new Terminal tab (whether over RDP or when I'm in front of the machine) the new tab will be OK and the existing tabs will still exhibit the issue.
- (Haven't tried. Will do so next time the issue occurs.)
- I haven't done a clean installation of Windows on this machine since 2009, so this seems like a promising avenue of investigation. Is there a way to enumerate all keyboard filter drivers on the system? I'm not finding useful results on Google for keyboard filter drivers in general, only specific keyboard filter drivers.
- Yes to history, no to sync. I don't think I've ever actually used clipboard history, but it's enabled and presumably has been for a while.
@Kufat I'd like to make sure you understood my question 2 above -- what I meant is to remote into the PC while you physically next to it (i.e. from another PC, laptop, tablet, or even a phone), reproduce the problem, then disconnect RDP session and walk up to the PC to test what happens when you login and type into affected wt tab using physical keyboard.
Regarding keyboard filters the only thing that comes to mind is this or searching the registry for keywords UpperFilters (not sure if keyboards also have LowerFilters) and finding entries related to keyboards:
On the other hand, something worth testing would be connecting another keyboard (simple cheap USB one), and connecting keyboard directly without KVM.
Finally, 2009 was a long time ago and I heard (aside from a hardware fault) there isn't any problem that can't be solved by reinstalling Windows.
@DHowett @zadjii-msft BTW, relatedly, I noticed today that we don't handle CONSOLE_IGNORE_NEXT_KEYUP in ConPTY/WT (just search it in the project if you're curious - it's only 4 matches). Edit: Opened #15662
I can reproduce an issue each time my computer wake up after sleep. It disappears when I open a new tab.
Version: 1.17.11461.0
I've never had this issue until today, but now all I have to do is change users and it happens on any open console. Version: 1.17.11461.0
I had this doing my first session on Azure Cloud Shell. Nice going Microsoft! I really like your product. Very impressive