ctrl-space not working inside remote desktop connection

[darthstark1138]

Environment

Windows build number: Microsoft Windows NT 10.0.19042.0
Windows Terminal version (if applicable): 1.3.2651.0

Any other software?
WIndows Remote Desktop Connection

Steps to reproduce

Example:

> ls<space><cursor><press ctrl-space>

Expected behavior

❯ ls
.ssh
AppData
Documents
> ls<space><cursor>

Actual behavior

> ls<space><space><cursor>

In other programs (ex.: Visual Studio) ctrl-space works normally.

[zadjii-msft]

What shell are you running in the Terminal (powershell, pwsh, cmd, bash, etc.)?

Do you have "experimental.input.forceVT": true in your settings by any chance?

[ghost]

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.

[darthstark1138]

Sorry, the notification went to spam.

The problem happens in Windows PowerShell and in Powershell Core 7.1.0 . Both in Windows terminal and Windows terminal preview. And only happens on my VM that I access with RDP.

I don't know about that experimental setting.

[zadjii-msft]

Okay here's another spitball question - what keyboard layout are you using? Does it have an AltGr key by any chance? If it has two ctrl keys, do both not work in the same way?

[ghost]

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.

[darthstark1138]

The keyboard layout is Brazilian ABNT-2. It has 2 Ctrl keys and neither work. It has an alt-gr key. It works as expected even inside terminal.
Also, ctrl-space works starting powershell as its own console.

[darthstark1138]

Another problem I just noticed: TAB is executed twice. Also only in Windows Terminal, does not happen on powershell or cmd consoles.

~> cd pic
Expected:
~> cd .\Picture
Actual:
~> cd '.\Pictures\Camera Roll'

~> cd d
Expected:
~> cd .\Desktop
Actual:
~> cd .\Documents\

[zadjii-msft]

@mvhecht Oh, the tab doubling thing is definitely interesting. Did you happen to try the InputServiceEnabled: 0 fix from #4448 in the past? That's the only known thing to cause tab to double like that, as well as cause other issues across the OS.

[darthstark1138]

I don't recall changing that, but it indeed was set to 0. So I set it back to 1 and restarted, then I made sure the Touch Keyboard service was running. Now neither terminal (stable or preview) recognizes any keyboard input. So I cried a little. Now I'm rereading the whole #4448 thread to see if there's anything that can help.

[zadjii-msft]

@mvhecht well that's even more batty. I guess you're now in the category of #8045. That OP was also using Remote Desktop. I don't really have an answer as to why that sometimes doesn't work, but that's the thread.

[darthstark1138]

Just an amendment, alt-gr + key combinations are the only ones that work now.
So I can type commands as long as they consist entirely of /?°¹²³£¢¬ and don't require an enter at the end.

[zadjii-msft]

Somehow that makes even less sense 😅 @lhecker you have any ideas why AltGr would work over Remote Desktop, but normal keys wouldn't? This makes it seem like we're filtering the keys Terminal-side. Without a local repro I'm not sure how to begin debugging this

[lhecker]

Which VM are you using @mvhecht? Does the VM run locally? And how did you connect using RDP?

[lhecker]

This issue could occur if some part of the Terminal <> TerminalInput has a flaw and returns false when a key event was handled and true if it actually wasn't. But I can't immediately see any such flaws in the code.

[darthstark1138]

Hi @lhecker ,

The VM runs on VMWare, and I access using plain old Windows Remote Desktop, but I also tried using mRemoteNg and it didn't make a difference. It's not local, it runs in my employer's data center.

Checking the #8045 thread I've decided to check ctfmon and it doesn't seem to be running, and also I can't start it, so that may be the problem. But, again, terminal is the only program where input doesn't work.

[ebadger]

Can you confirm that ctfmon.exe is running and that the PID is stable?

[darthstark1138]

Can you confirm that ctfmon.exe is running and that the PID is stable?

No, actually I can confirm that it's not running, and that I can't start it in any way. Not sure why is that; I'm researching solutions to that now.

[darthstark1138]

In the end...

A Group Policy from my organization was not only disabling the service, but killing ctfmon.exe a few seconds after I started it.

After I got them to remove that policy and rebooted everything is working.

Thanks all and sorry for the trouble.

[zadjii-msft]

Don't worry about it! I'm glad you found a solution to the issue - I've never heard of anyone doing that with a Group Policy before. That's certainly something that won't work the way they hope, and I'm sorry you got caught on the bad end of that. We'll keep an eye out for other users with similar situations in the future.

[lhecker]

@mvhecht That's really interesting! I wouldn't have thought of using policies for that. 😯
If your organization still uses this group policy anywhere else I'd strongly suggest not disabling that service though. It used to be part of Office a long time ago, but nowadays it's an integral part of Windows. For instance without ctfmon any input in UWP applications - including those that are part of Windows itself, like the search bar - will not work properly. It should only use about 5MB memory and no CPU under normal conditions.