starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-02-04 05:35:20 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

DISCUSSION: Continued commentary about the touch keyboard service #11946

New Issue
Open
opened 2026-01-31 03:01:52 +00:00 by claunia · 33 comments
claunia commented 2026-01-31 03:01:52 +00:00
Owner
Copy Link

Originally created by @levicki on GitHub (Jan 3, 2021).

Originally assigned to: @ebadger on GitHub.

MAINTAINER EDIT: OP here is a rant that disparages my colleague, and frankly, I'm not gonna stand for that.

You can click here to view it if you want, but I'm not gonna let a flame war evolve.

The five users we've encountered who have disabled this service and inexplicably have a working input stack are in the extreme minority, and they can deal with it fairly trivially.

Congratulations, every response you gave so far on the issue of Touch Keyboard and Handwriting service warning just serves to reinforce the widespread opinion that most Microsoft developers are self-righteous assholes who enjoy antagonizing power-users and developers alike.

We'll probably add a setting or something, but not after raising the hackles of power users who are certain they understand the operating system.

We seem to have better overall understanding of Windows than you do, not to mention that we were trying our best to be polite instead of condescending like you.

You have an overview from some source called "lifewire" as to what ctfmon.exe does, and we have the person who owns that executable explaining to us how the input stack works and why it's required for modern apps. I know which one I'm inclined to trust.

Obviously your trust does not mean you actually understand their explanation or otherwise you would realize that said service is totally unnecessary for all apps on a desktop system and that you are being an ass by condemning a class of PC users (and not just power users and fellow developers mind you) to an otherwise totally avoidable annoyance because you are obviously on a power trip and like "slapping users in the face" with warnings. Good thing your reach does not extend beyond our desktop or you might try slapping us for real given the show of your character here.

I am sure there are many good people among developers in Microsoft -- Raymond Chen, Larry Osterman, and a few others come to mind. You Sir are not one of them and you should be ashamed of yourself.

I hope someone from Microsoft HR department sees this and the other threads here and your outright hostility towards customers gets taken down a notch or two.

Originally created by @levicki on GitHub (Jan 3, 2021). Originally assigned to: @ebadger on GitHub. MAINTAINER EDIT: <em> OP here is a rant that disparages my colleague, and frankly, I'm not gonna stand for that. </em> <details> <summary> You can click here to view it if you want, but I'm not gonna let a flame war evolve. </summary> > The five users we've encountered who have disabled this service and inexplicably have a working input stack are in the extreme minority, and they can _deal with it_ fairly trivially. Congratulations, every response you gave so far on the issue of Touch Keyboard and Handwriting service warning just serves to reinforce the widespread opinion that most Microsoft developers are self-righteous assholes who enjoy antagonizing power-users and developers alike. > We'll probably add a setting or something, but not after raising the hackles of power users who are certain they understand the operating system. We seem to have better overall understanding of Windows than you do, not to mention that we were trying our best to be polite instead of condescending like you. > You have an overview from some source called "lifewire" as to what ctfmon.exe does, and we have the person who owns that executable explaining to us how the input stack works and why it's required for modern apps. I know which one I'm inclined to trust. Obviously your trust does not mean you actually understand their explanation or otherwise you would realize that said service is totally unnecessary for all apps on a desktop system and that you are being an ass by condemning a class of PC users (and not just power users and fellow developers mind you) to an otherwise totally avoidable annoyance because you are obviously on a power trip and like "slapping users in the face" with warnings. Good thing your reach does not extend beyond our desktop or you might try slapping us for real given the show of your character here. I am sure there are many good people among developers in Microsoft -- Raymond Chen, Larry Osterman, and a few others come to mind. You Sir are not one of them and you should be ashamed of yourself. I hope someone from Microsoft HR department sees this and the other threads here and your outright hostility towards customers gets taken down a notch or two. </details>
claunia added the Issue-QuestionNeeds-Tag-FixProduct-Terminal labels 2026-01-31 03:01:53 +00:00
claunia commented 2026-01-31 03:01:54 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 3, 2021):

Igor,

My job here is to make a call. Sometimes those calls are wrong, and I'm willing to accept that. I apologize. I made a bad call.

you would realize that said service is totally unnecessary

I can only draw on the knowledge of my peers here. The folks who own ctfmon explained why it's an integral part of the "modern application input stack¹," and they didn't give any leeway. We're still working with them to figure out why applications work without it. Every bit of knowledge we have in the company suggests that they shouldn't.

I've filed https://github.com/microsoft/terminal/issues/8699 as a followup to discuss how we can make the experience better for you.

¹ Even though it's named "touch keyboard and handwriting". The name is no longer fitting: it is designed to handle all input for all XAML/UWP applications. It should be renamed!

@DHowett commented on GitHub (Jan 3, 2021): Igor, My job here is to make a call. Sometimes those calls are wrong, and I'm willing to accept that. I apologize. I made a bad call. > you would realize that said service is totally unnecessary I can only draw on the knowledge of my peers here. The folks who own ctfmon explained why it's an integral part of the "modern application input stack¹," and they didn't give any leeway. We're still working with them to figure out why applications _work_ without it. Every bit of knowledge we have in the company suggests that they shouldn't. I've filed https://github.com/microsoft/terminal/issues/8699 as a followup to discuss how we can make the experience better for you. ¹ Even though it's named "touch keyboard and handwriting". The name is no longer fitting: it is designed to handle all input for all XAML/UWP applications. It should be renamed!
claunia commented 2026-01-31 03:01:55 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 4, 2021):

I'm going to keep this issue unlocked. It wouldn't be fair for me to (continue to) shut down discussion. /cc @mdcclxv

mdcclxv: we're a small team, and we've historically needed to constrain our work to supported OS configurations. I'm not saying we don't have bandwidth to work on the fix... it's just that somebody with a greater need than us would be better suited to working on the problem.

@DHowett commented on GitHub (Jan 4, 2021): I'm going to keep this issue unlocked. It wouldn't be fair for me to (continue to) shut down discussion. /cc @mdcclxv mdcclxv: we're a small team, and we've historically needed to constrain our work to supported OS configurations. I'm not saying we don't have bandwidth to work on the fix... it's just that somebody with a greater need than us would be better suited to working on the problem.
claunia commented 2026-01-31 03:01:55 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 4, 2021):

@DHowett

Thank you for being frank and owning up to your mistake.

I understand that Windows input stack is a complex beast and that what works for me might not work for everyone.

I do not mind seeing a warning provided that it can be disabled afterwards so I do not have to dismiss it every time I launch Windows Terminal which is one of the very few modern apps I use.

What was really annoying in all this was that it seemed the service warning was an indirect fix for ctfmon.exe not running and it also seems you are still unsure why and how we don't have any issues with the service disabled and ctfmon.exe not running.

I even went as far as to delete the service completely (after backing up the registry key of course) to test your claims and my Windows 10 Version 20H2 still processes keyboard input normally in all applications including Windows Terminal, and ctfmon.exe is nowhere to be found in my Task Manager.

I am more than willing to collaborate by providing you with any feedback, logs, or by performing any tests necessary on my system for you to figure out how is that possible if that will help you make a better solution for everyone. Let me know if there is anytihng I can contribute.

As for the sevice name, it does fit partially because if I am not mistaken it is responsible for bringing up the on-screen keyboard. That is one of the reasons many of us disable it right away.

Finally, I don't think it is a good idea for any application to be an "enforcer" for system services, no matter how critical those services might be for some use(r)s. Today it is Touch Keyboard service, tomorrow you will be adding checks and warnings for DNS client service so that ping command can resolve host names. Where does it end?

IMO, showing the warning once or even just adding "My keyboard doesn't work" section to FAQ should be more than enough help tor people with no input issue -- you should not try to fix all problems with software and most definitely making sure that ctfmon.exe is running should not be your responsibility because you are not the owner.

@levicki commented on GitHub (Jan 4, 2021): @DHowett Thank you for being frank and owning up to your mistake. I understand that Windows input stack is a complex beast and that what works for me might not work for everyone. I do not mind seeing a warning provided that it can be disabled afterwards so I do not have to dismiss it every time I launch Windows Terminal which is one of the very few modern apps I use. What was really annoying in all this was that it seemed the service warning was an indirect fix for ctfmon.exe not running and it also seems you are still unsure why and how we don't have any issues with the service disabled and ctfmon.exe not running. I even went as far as to delete the service completely (after backing up the registry key of course) to test your claims and my Windows 10 Version 20H2 still processes keyboard input normally in all applications including Windows Terminal, and ctfmon.exe is nowhere to be found in my Task Manager. I am more than willing to collaborate by providing you with any feedback, logs, or by performing any tests necessary on my system for you to figure out how is that possible if that will help you make a better solution for everyone. Let me know if there is anytihng I can contribute. As for the sevice name, it does fit partially because if I am not mistaken it is responsible for bringing up the on-screen keyboard. That is one of the reasons many of us disable it right away. Finally, I don't think it is a good idea for any application to be an "enforcer" for system services, no matter how critical those services might be for some use(r)s. Today it is Touch Keyboard service, tomorrow you will be adding checks and warnings for DNS client service so that ping command can resolve host names. Where does it end? IMO, showing the warning once or even just adding "My keyboard doesn't work" section to FAQ should be more than enough help tor people with no input issue -- you should not try to fix all problems with software and most definitely making sure that ctfmon.exe is running should not be your responsibility because you are not the owner.
claunia commented 2026-01-31 03:01:56 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Jan 4, 2021):

Alright, so on topic:

@levicki You've got the service disabled, and ctfmon.exe isn't running. Can you type into the search box in the settings app?

/cc @ebadger

@zadjii-msft commented on GitHub (Jan 4, 2021): Alright, so on topic: @levicki You've got the service disabled, and `ctfmon.exe` isn't running. Can you type into the search box in the settings app? /cc @ebadger
claunia commented 2026-01-31 03:01:56 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 4, 2021):

Yes, of course I can:

image

@levicki commented on GitHub (Jan 4, 2021): Yes, of course I can: ![image](https://user-images.githubusercontent.com/16415478/103572147-69304c80-4ecc-11eb-8e41-3f470637a6f1.png)
claunia commented 2026-01-31 03:01:57 +00:00
Author
Owner
Copy Link

@ebadger commented on GitHub (Jan 4, 2021):

please send result from command prompt of

"tasklist | findstr /i ctfmon"

Also, please send result of:

"reg query hklm\software\microsoft\input"

Also, please send result of:

"ver"

Thanks

Eric

@ebadger commented on GitHub (Jan 4, 2021): please send result from command prompt of "tasklist | findstr /i ctfmon" Also, please send result of: "reg query hklm\software\microsoft\input" Also, please send result of: "ver" Thanks Eric
claunia commented 2026-01-31 03:01:57 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 4, 2021):

@ebadger

image

@levicki commented on GitHub (Jan 4, 2021): @ebadger ![image](https://user-images.githubusercontent.com/16415478/103573001-c8429100-4ecd-11eb-9cd3-f784e198de50.png)
claunia commented 2026-01-31 03:01:58 +00:00
Author
Owner
Copy Link

@ebadger commented on GitHub (Jan 4, 2021):

@ebadger

image

could you provide results of "ver" command as well?

@ebadger commented on GitHub (Jan 4, 2021): > @ebadger > > ![image](https://user-images.githubusercontent.com/16415478/103573001-c8429100-4ecd-11eb-9cd3-f784e198de50.png) could you provide results of "ver" command as well?
claunia commented 2026-01-31 03:01:58 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 4, 2021):

Microsoft Windows [Version 10.0.19042.685]

@levicki commented on GitHub (Jan 4, 2021): `Microsoft Windows [Version 10.0.19042.685]`
claunia commented 2026-01-31 03:01:59 +00:00
Author
Owner
Copy Link

@ebadger commented on GitHub (Jan 4, 2021):

would you mind trying : C:\WINDOWS\system32>tasklist /m inputservice.dll

@ebadger commented on GitHub (Jan 4, 2021): would you mind trying : C:\WINDOWS\system32>tasklist /m inputservice.dll
claunia commented 2026-01-31 03:01:59 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 4, 2021):

@ebadger Sure

image

@levicki commented on GitHub (Jan 4, 2021): @ebadger Sure ![image](https://user-images.githubusercontent.com/16415478/103573492-a0076200-4ece-11eb-959c-eb4b75a58ea1.png)
claunia commented 2026-01-31 03:02:00 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 4, 2021):

image

@levicki commented on GitHub (Jan 4, 2021): ![image](https://user-images.githubusercontent.com/16415478/103573695-f1afec80-4ece-11eb-967d-d6cf9ae77006.png)
claunia commented 2026-01-31 03:02:00 +00:00
Author
Owner
Copy Link

@ebadger commented on GitHub (Jan 4, 2021):

looks like our service is running via a legacy instantiation path.
If you kill that taskhostw.exe instance, text input will stop working in your settings app and in terminal.
typically the service is hosted in ctfmon.exe and it's lifetime is managed by the tablet input service.

Try terminating the taskhostw.exe instance and see if you can type in terminal / settings.
I'll guess that it won't work until you either log off/log back in, or go and manually kick off the scheduled task.

@ebadger commented on GitHub (Jan 4, 2021): looks like our service is running via a legacy instantiation path. If you kill that taskhostw.exe instance, text input will stop working in your settings app and in terminal. typically the service is hosted in ctfmon.exe and it's lifetime is managed by the tablet input service. Try terminating the taskhostw.exe instance and see if you can type in terminal / settings. I'll guess that it won't work until you either log off/log back in, or go and manually kick off the scheduled task.
claunia commented 2026-01-31 03:02:00 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 4, 2021):

Before I proceed, could you please clarify:

  1. At which Windows feature update has this became a legacy instantiation path?
  2. What mechanism governs which instantiation path is used?

Please advise.

To clarify, I am asking this because I am curious to learn whether having a fresh OS install will result in a different behavior compared to going say from 1809 through several feature updates to 20H2.

@levicki commented on GitHub (Jan 4, 2021): Before I proceed, could you please clarify: 1. At which Windows feature update has this became a legacy instantiation path? 2. What mechanism governs which instantiation path is used? Please advise. To clarify, I am asking this because I am curious to learn whether having a fresh OS install will result in a different behavior compared to going say from 1809 through several feature updates to 20H2.
claunia commented 2026-01-31 03:02:01 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 4, 2021):

@ebadger @zadjii-msft

I killed the taskhostw.exe instance and I cannot type in Settings app search box anymore, but...

image

Now what? Would TextInputHost.exe have anything to do with Windows Terminal still being able to receive input?

EDIT: Nope, killed TextInputHost.exe as well and Windows Terminal input still working.

@levicki commented on GitHub (Jan 4, 2021): @ebadger @zadjii-msft I killed the `taskhostw.exe` instance and I cannot type in Settings app search box anymore, but... ![image](https://user-images.githubusercontent.com/16415478/103575167-93d0d400-4ed1-11eb-80f7-b7dc99112987.png) Now what? Would `TextInputHost.exe` have anything to do with Windows Terminal still being able to receive input? **EDIT:** Nope, killed `TextInputHost.exe` as well and Windows Terminal input still working.
claunia commented 2026-01-31 03:02:01 +00:00
Author
Owner
Copy Link

@piscisaureus commented on GitHub (Jan 5, 2021):

image

image

@piscisaureus commented on GitHub (Jan 5, 2021): ![image](https://user-images.githubusercontent.com/218257/103606552-8ca6c780-4ecb-11eb-9ab7-741fc0f4839f.png) ![image](https://user-images.githubusercontent.com/218257/103607100-00959f80-4ecd-11eb-835e-724ae0babdb0.png)
claunia commented 2026-01-31 03:02:02 +00:00
Author
Owner
Copy Link

@ebadger commented on GitHub (Jan 5, 2021):

@levicki and @piscisaureus, after some digging I've discovered some interesting information.

Terminal is actually win32 hosting, not UWP, so the input integration is slightly different. This enables normal keyboard input without the service running. Also have discovered that in this unsupported configuration, there is a problem with terminal on startup that prevents normal text input.

You should be able to reproduce text input not working in terminal by disabling the tablet input service and rebooting.
On reboot, the legacy / fallback initialization of the input service will occur. This is OK for start and settings, but breaks terminal.
You won't be able to type in terminal at this point. If you terminate the tashostw.exe that is hosting the input service, you'll be able to type in terminal, but not in start / settings / UWPs.

Ideal configuration here would be to re-enable the tablet input service, and allow ctfmon.exe to launch - this will resolve text input issues into both UWP and Terminal. The current technique of disabling the tabletinputservice doesn't actually buy you much anyway due to the fallback initialization of the input service - i.e. it's just hosted in taskhostw.exe instead.

Again, would recommend that you enable tablet input service and allow ctfmon.exe to work properly.

@ebadger commented on GitHub (Jan 5, 2021): @levicki and @piscisaureus, after some digging I've discovered some interesting information. Terminal is actually win32 hosting, not UWP, so the input integration is slightly different. This enables normal keyboard input without the service running. Also have discovered that in this unsupported configuration, there is a problem with terminal on startup that prevents normal text input. You should be able to reproduce text input not working in terminal by disabling the tablet input service and rebooting. On reboot, the legacy / fallback initialization of the input service will occur. This is OK for start and settings, but breaks terminal. You won't be able to type in terminal at this point. If you terminate the tashostw.exe that is hosting the input service, you'll be able to type in terminal, but not in start / settings / UWPs. Ideal configuration here would be to re-enable the tablet input service, and allow ctfmon.exe to launch - this will resolve text input issues into both UWP and Terminal. The current technique of disabling the tabletinputservice doesn't actually buy you much anyway due to the fallback initialization of the input service - i.e. it's just hosted in taskhostw.exe instead. Again, would recommend that you enable tablet input service and allow ctfmon.exe to work properly.
claunia commented 2026-01-31 03:02:03 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Jan 5, 2021):

@ebadger We should dig into the Terminal issue. We're just using Xaml Islands, so I suspect the issue is somewhere between your code and mine.

I'm a bit confused about this part though:

... text input not working in terminal by disabling the tablet input service and rebooting ...
... This is OK for start and settings, but breaks terminal ...

@levicki seems to be experiencing the fallback behavior (the service is disabled), but Terminal is working until he terminates the taskhost hosting the fallback service. Is there a third state where Terminal works and Settings works without the usual service running?

@DHowett commented on GitHub (Jan 5, 2021): @ebadger We should dig into the Terminal issue. We're just using Xaml Islands, so I suspect the issue is somewhere between your code and mine. I'm a bit confused about this part though: > ... text input not working in terminal by disabling the tablet input service and rebooting ... > ... This is OK for start and settings, but breaks terminal ... @levicki seems to be experiencing the fallback behavior (the service is disabled), but Terminal _is working_ until he terminates the taskhost hosting the fallback service. Is there a third state where Terminal works _and_ Settings works without the usual service running?
claunia commented 2026-01-31 03:02:03 +00:00
Author
Owner
Copy Link

@piscisaureus commented on GitHub (Jan 5, 2021):

@ebadger

@levicki seems to be experiencing the fallback behavior (the service is disabled), but Terminal is working until he terminates the taskhost hosting the fallback service. Is there a third state where Terminal works and Settings works without the usual service running?

I have TabletInputService set to disabled too, and both settings search and terminal work fine. Killing taskhostw.exe does break settings search but terminal continues to work.

While I have the eyeballs of someone on the input team: I'd be more than okay with enabling TabletInputService if it weren't that it makes keyboard input terribly laggy in certain applications (see https://github.com/microsoft/terminal/issues/8228#issuecomment-734951751). Fixing the "root cause" seems better than adding a workaround to support another workaround.

@piscisaureus commented on GitHub (Jan 5, 2021): @ebadger > @levicki seems to be experiencing the fallback behavior (the service is disabled), but Terminal _is working_ until he terminates the taskhost hosting the fallback service. Is there a third state where Terminal works _and_ Settings works without the usual service running? I have TabletInputService set to `disabled` too, and both settings search and terminal work fine. Killing `taskhostw.exe` does break settings search but terminal continues to work. While I have the eyeballs of someone on the input team: I'd be more than okay with enabling TabletInputService if it weren't that it makes keyboard input terribly laggy in certain applications (see https://github.com/microsoft/terminal/issues/8228#issuecomment-734951751). Fixing the "root cause" seems better than adding a workaround to support another workaround.
claunia commented 2026-01-31 03:02:04 +00:00
Author
Owner
Copy Link

@ebadger commented on GitHub (Jan 5, 2021):

@ebadger

@levicki seems to be experiencing the fallback behavior (the service is disabled), but Terminal is working until he terminates the taskhost hosting the fallback service. Is there a third state where Terminal works and Settings works without the usual service running?

I have TabletInputService set to disabled too, and both settings search and terminal work fine. Killing taskhostw.exe does break settings search but terminal continues to work.

While I have the eyeballs of someone on the input team: I'd be more than okay with enabling TabletInputService if it weren't that it makes keyboard input terribly laggy in certain applications (see #8228 (comment)). Fixing the "root cause" seems better than adding a workaround to support another workaround.

wrt to your comment on 8228. If you're using hardware keyboard, and not using an IME, there should be ~0 impact on perf during typing for Chrome or VS Code. You mentioned procmon showing ctfmon.exe starting and stopping on each keystroke - this indicates something is wrong - either configuration issue or a bug. ctfmon.exe is a long running service and is not expected to fail.

@ebadger commented on GitHub (Jan 5, 2021): > @ebadger > > > @levicki seems to be experiencing the fallback behavior (the service is disabled), but Terminal _is working_ until he terminates the taskhost hosting the fallback service. Is there a third state where Terminal works _and_ Settings works without the usual service running? > > I have TabletInputService set to `disabled` too, and both settings search and terminal work fine. Killing `taskhostw.exe` does break settings search but terminal continues to work. > > While I have the eyeballs of someone on the input team: I'd be more than okay with enabling TabletInputService if it weren't that it makes keyboard input terribly laggy in certain applications (see [#8228 (comment)](https://github.com/microsoft/terminal/issues/8228#issuecomment-734951751)). Fixing the "root cause" seems better than adding a workaround to support another workaround. wrt to your comment on 8228. If you're using hardware keyboard, and not using an IME, there should be ~0 impact on perf during typing for Chrome or VS Code. You mentioned procmon showing ctfmon.exe starting and stopping on each keystroke - this indicates something is wrong - either configuration issue or a bug. ctfmon.exe is a long running service and is not expected to fail.
claunia commented 2026-01-31 03:02:04 +00:00
Author
Owner
Copy Link

@levicki commented on GitHub (Jan 6, 2021):

@ebadger


Also have discovered that in this unsupported configuration, there is a problem with terminal on startup that prevents normal text input.

I have not observed this, what are your repro steps?

You should be able to reproduce text input not working in terminal by disabling the tablet input service and rebooting.

When I was performing your tests the service was not even installed -- I deleted it using sc delete previously and rebooted. Terminal and everything else still worked.

If you terminate the tashostw.exe that is hosting the input service, you'll be able to type in terminal, but not in start / settings / UWPs.

I can confirm Settings not working after killing taskhostw.exe, but I am able to type into the Terminal both before and after killing taskhostw.exe. Closing and reopening Terminal at any point does not change this fact either.

The current technique of disabling the tabletinputservice doesn't actually buy you much anyway due to the fallback initialization of the input service - i.e. it's just hosted in taskhostw.exe instead.

The reason I am disabling it is because I do not need its functionality on my desktop.

Furthermore, Microsoft says it is OK to do so as part of security hardening:

https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/security/windows-services/security-guidelines-for-disabling-system-services-in-windows-server.md#touch-keyboard-and-handwriting-panel-service

Again, would recommend that you enable tablet input service and allow ctfmon.exe to work properly.

There was also the time when ctfmon had tons of vulnerabilities discovered by Google Project Zero researcher Tavis Ormandy (hopefully fixed by now):

https://github.com/taviso/ctftool

So no thanks, I would rather keep the services I do not need disabled to reduce the attack surface. Sadly, Microsoft keeps adding useless services thus making my job as system admin ever harder.

I wonder, did it occur to anyone on the input team that keyboard input should not be handled in a service or a process that a user can stop or kill?

Is there any benefit to current compartmentalization compared to say running it under System process (PID 4) or some other unkillable OS process so that it always works for all apps?

@levicki commented on GitHub (Jan 6, 2021): @ebadger  > Also have discovered that in this unsupported configuration, there is a problem with terminal on startup that prevents normal text input. I have not observed this, what are your repro steps? > You should be able to reproduce text input not working in terminal by disabling the tablet input service and rebooting. When I was performing your tests the service was not even installed -- I deleted it using sc delete previously and rebooted. Terminal and everything else still worked. > If you terminate the tashostw.exe that is hosting the input service, you'll be able to type in terminal, but not in start / settings / UWPs. I can confirm Settings not working after killing taskhostw.exe, but I am able to type into the Terminal both before and after killing taskhostw.exe. Closing and reopening Terminal at any point does not change this fact either. > The current technique of disabling the tabletinputservice doesn't actually buy you much anyway due to the fallback initialization of the input service - i.e. it's just hosted in taskhostw.exe instead. The reason I am disabling it is because I do not need its functionality on my desktop. Furthermore, Microsoft says it is OK to do so as part of security hardening: https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/security/windows-services/security-guidelines-for-disabling-system-services-in-windows-server.md#touch-keyboard-and-handwriting-panel-service > Again, would recommend that you enable tablet input service and allow ctfmon.exe to work properly. There was also the time when ctfmon had tons of vulnerabilities discovered by Google Project Zero researcher Tavis Ormandy (hopefully fixed by now): https://github.com/taviso/ctftool So no thanks, I would rather keep the services I do not need disabled to reduce the attack surface. Sadly, Microsoft keeps adding useless services thus making my job as system admin ever harder. I wonder, did it occur to anyone on the input team that keyboard input should not be handled in a service or a process that a user can stop or kill? Is there any benefit to current compartmentalization compared to say running it under System process (PID 4) or some other unkillable OS process so that it always works for all apps?
claunia commented 2026-01-31 03:02:05 +00:00
Author
Owner
Copy Link

@dcs619 commented on GitHub (Jan 18, 2021):

Found this thread after following the security hardening link and discovering that Terminal doesn't accept keyboard input without the touch service running.

Happy to provide any testing I can -- Powershell accepts keyboard input correctly without the touch service.

@dcs619 commented on GitHub (Jan 18, 2021): Found this thread after following the security hardening link and discovering that Terminal doesn't accept keyboard input without the touch service running. Happy to provide any testing I can -- Powershell accepts keyboard input correctly without the touch service.
claunia commented 2026-01-31 03:02:05 +00:00
Author
Owner
Copy Link

@amard33p commented on GitHub (Oct 2, 2021):

Enabling Touch Keyboard to support Windows Terminal service causes the On Screen Keyboard to appear in the login screen. I don't see any use of OSK when you have an actual physical keyboard or biometric login enabled.

I understand that the team may be already aware of this issue but I wanted to put it out here since this is the only open issue on the topic.

@amard33p commented on GitHub (Oct 2, 2021): Enabling Touch Keyboard to support Windows Terminal service causes the On Screen Keyboard to appear in the login screen. I don't see any use of OSK when you have an actual physical keyboard or biometric login enabled. I understand that the team may be already aware of this issue but I wanted to put it out here since this is the only open issue on the topic.
claunia commented 2026-01-31 03:02:05 +00:00
Author
Owner
Copy Link

@LinuxOnTheDesktop commented on GitHub (Nov 3, 2022):

Here are what seem to me to be three problems with the warning shown here:

image

Problem 1: the warning does not impart that the terminal needs the service even if one is using a normal keyboard.

Problem 2: the warning does not impart that after the service has been enabled the user will need to restart the machine in order for the terminal to receipt keyboard input.

Problem 3: the warning does not impart whether setting the service to 'manual' suffices.

I will open a new issue for this, should that be desired.

@LinuxOnTheDesktop commented on GitHub (Nov 3, 2022): Here are what seem to me to be three problems with the warning shown here: ![image](https://user-images.githubusercontent.com/47056543/199694293-fd723025-d5d0-4c96-8a41-f679fb0953c6.png) Problem 1: the warning does not impart that the terminal needs the service _even if one is using a normal keyboard_. Problem 2: the warning does not impart that after the service has been enabled the user will need to _restart_ the machine in order for the terminal to receipt keyboard input. Problem 3: the warning does not impart whether _setting the service to 'manual'_ suffices. I will open a new issue for this, should that be desired.
claunia commented 2026-01-31 03:02:06 +00:00
Author
Owner
Copy Link

@KalleOlaviNiemitalo commented on GitHub (Nov 3, 2022):

If additional text were added to the warning itself, then it might become so long that users would entirely skip reading it. A "More info" button could be safer in that respect. Should the info be included in the Terminal package or should the button open a web page? Access to a web page might be blocked by a firewall, and Microsoft would not see that problem via telemetry because the firewall would likely block the telemetry as well.

@KalleOlaviNiemitalo commented on GitHub (Nov 3, 2022): If additional text were added to the warning itself, then it might become so long that users would entirely skip reading it. A "More info" button could be safer in that respect. Should the info be included in the Terminal package or should the button open a web page? Access to a web page might be blocked by a firewall, and Microsoft would not see that problem via telemetry because the firewall would likely block the telemetry as well.
claunia commented 2026-01-31 03:02:06 +00:00
Author
Owner
Copy Link

@synap5e commented on GitHub (Feb 9, 2023):

I'm unable type in the terminal of my Azure Cloud PC.
Unsure if TabletInputService has been disabled as part of security hardening for our org or having it off is a default for CPCs, but could check.

@synap5e commented on GitHub (Feb 9, 2023): I'm unable type in the terminal of my Azure Cloud PC. Unsure if TabletInputService has been disabled as part of security hardening for our org or having it off is a default for CPCs, but could check.
claunia commented 2026-01-31 03:02:06 +00:00
Author
Owner
Copy Link

@Redundanz commented on GitHub (Apr 16, 2023):

this is addressed to MS management not devs. NT 10.0+ really has become a kludge, patchwork!

i came here because i was experiencing no possible input in "settings" app search field looking for solutions. turns out that a service specified for tablet/touch devices is the dependency. i don't own nor use such device.

and one would think it wouldn't be hard to rename at least the description of said service to something like "basic input managment service" (for the time being, because in all honesty, text input, THE MOST BASIC...PRIMORDIAL USE OF A COMPUTER should not be depending on such non-critical-seeming service running. especially if it leads to a discrimination of where i can and can't input text. but basically the service somehow got promoted to "csrss2" ;-) for certain (appx/uwp?!) text inputs. then it should be protected just as much and be named according to its importance/relevance.

but i consider it moot to go deeper into discussion about technicalities. it is obvious that the whole fundament of NT has become patchwork and instead of cleaning up BASELINE dependencies you have meaningless arbitrary superficial features added to keep some "sheep" fascinated about monthly "new insider builds". MS management (!!! not devs) chose the to further extend a dilapidated house while it actually needs renovation & sanitation from ground up first and foremost.

redo the registry. redo service landscape. redo os file base. simplify & declutter your OS core before adding +1 to versions because you changed window corners to rounded (which ppl would have done with shell mods in NT 5.2 - 6.x times if they were so keen on it). more intelligent solutions would involve a clickable checkbox in theme options...

@Redundanz commented on GitHub (Apr 16, 2023): this is addressed to MS management not devs. NT 10.0+ really has become a kludge, patchwork! i came here because i was experiencing no possible input in "settings" app search field looking for solutions. turns out that a service specified for tablet/touch devices is the dependency. i don't own nor use such device. and one would think it wouldn't be _*hard*_ to rename _*at least*_ the description of said service to something like "basic input managment service" (for the time being, because in all honesty, text input, _*THE MOST BASIC...PRIMORDIAL USE OF A COMPUTER*_ should not be depending on such non-critical-seeming service running. especially if it leads to a discrimination of where i can and can't input text. but basically the service somehow got promoted to "csrss2" ;-) for certain (appx/uwp?!) text inputs. then it should be protected just as much and be named according to its importance/relevance. but i consider it moot to go deeper into discussion about technicalities. it is obvious that the whole fundament of NT has become patchwork and instead of cleaning up BASELINE dependencies you have meaningless arbitrary superficial features added to keep some "sheep" fascinated about monthly "new insider builds". MS management (!!! not devs) chose the to further _*extend*_ a dilapidated house while it actually needs _*renovation*_ & _*sanitation*_ from ground up first and foremost. redo the registry. redo service landscape. redo os file base. _*simplify*_ & _*declutter*_ your OS core before adding +1 to versions because you changed window corners to rounded (which ppl would have done with shell mods in NT 5.2 - 6.x times if they were so keen on it). more intelligent solutions would involve a clickable checkbox in theme options...
claunia commented 2026-01-31 03:02:07 +00:00
Author
Owner
Copy Link

@bluearcher-bc commented on GitHub (Nov 26, 2023):

Win11 2H23 (although I only updated to this build AFTER this issue started occurring)
I really hate to latch on to this thread, but this seems to be where all the important knowledge on this topic lies. As of a week or two ago, my ctfmon.exe has started crashing constantly, potentially every time I try to type somewhere it is required. At a minimum I have issues inputting text in places like start menu, settings, calculator, Unigram, etc. I have been unable to stabilize ctfmon.exe using numerous techniques described in this page and elsewhere. A lot of the conventional wisdom on this process seems to originate from Win10 days when it genuinely was not required and many people disabled it.

Long story short, where can I go for more detailed help figuring out why this process constantly crashes?

I have attached the output of WinDbg on a mini dump of a recent crash.

Microsoft (R) Windows Debugger Version 10.0.25921.1001 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\Users\<snip>\AppData\Local\CrashDumps\ctfmon.exe.26676.dmp]
User Mini Dump File: Only registers, stack and portions of memory are available


************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*
Symbol search path is: srv*
Executable search path is: 
Windows 10 Version 22631 MP (6 procs) Free x64
Product: WinNt, suite: SingleUserTS
Edition build lab: 22621.1.amd64fre.ni_release.220506-1250
Debug session time: Sun Nov 26 11:57:27.000 2023 (UTC - 5:00)
System Uptime: not available
Process Uptime: 0 days 0:00:01.000
...................................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(6834.5648): Security check failure or stack buffer overrun - code c0000409 (first/second chance not available)
Subcode: 0x7 FAST_FAIL_FATAL_APP_EXIT 
For analysis of this file, run !analyze -v
KERNELBASE!RaiseFailFastException+0x152:
00007ffe`6b07c3b2 0f1f440000      nop     dword ptr [rax+rax]
0:014> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

*** WARNING: Check Image - Checksum mismatch - Dump: 0x4a49e7, File: 0x4a4b8d - C:\ProgramData\Dbg\sym\InputService.dll\2229545C4bb000\InputService.dll
DEBUG_FLR_EXCEPTION_CODE(80070057) and the ".exr -1" ExceptionCode(c0000409) don't match

KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 921

    Key  : Analysis.Elapsed.mSec
    Value: 938

    Key  : Analysis.IO.Other.Mb
    Value: 0

    Key  : Analysis.IO.Read.Mb
    Value: 0

    Key  : Analysis.IO.Write.Mb
    Value: 0

    Key  : Analysis.Init.CPU.mSec
    Value: 171

    Key  : Analysis.Init.Elapsed.mSec
    Value: 22137

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 123

    Key  : FailFast.Name
    Value: FATAL_APP_EXIT

    Key  : FailFast.Type
    Value: 7

    Key  : Failure.Bucket
    Value: FAIL_FAST_FATAL_APP_EXIT_80070057_InputService.dll!_lambda_e9c081f003eb6b2a1a472fadecf202ae_::operator

    Key  : Failure.Hash
    Value: {244d2e09-2701-2fb9-7de3-c7110c080dac}

    Key  : Timeline.Process.Start.DeltaSec
    Value: 1

    Key  : WER.OS.Branch
    Value: ni_release

    Key  : WER.OS.Version
    Value: 10.0.22621.1

    Key  : WER.Process.Version
    Value: 10.0.22621.1


FILE_IN_CAB:  ctfmon.exe.26676.dmp

NTGLOBALFLAG:  0

APPLICATION_VERIFIER_FLAGS:  0

CONTEXT:  (.ecxr)
rax=000000881cb7d8c0 rbx=000000881cb7de40 rcx=000000881cb7d8c0
rdx=000000881cb7dd70 rsi=000000881cb7de40 rdi=000000881cb7d8c0
rip=00007ffe6b07c3b2 rsp=000000881cb7d7e0 rbp=0000000000000001
 r8=0000000000000000  r9=000000881cb7dd20 r10=00000fffcd60f84d
r11=0000000000002000 r12=0000000000000001 r13=0000000000000000
r14=0000000000000000 r15=00007ffdd794cce6
iopl=0         nv up ei pl nz na po nc
cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00000204
KERNELBASE!RaiseFailFastException+0x152:
00007ffe`6b07c3b2 0f1f440000      nop     dword ptr [rax+rax]
Resetting default scope

EXCEPTION_RECORD:  (.exr -1)
ExceptionAddress: 00007ffdd794cce6 (InputService!<lambda_e9c081f003eb6b2a1a472fadecf202ae>::operator()+0x00000000000002b2)
   ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
  ExceptionFlags: 00000001
NumberParameters: 3
   Parameter[0]: 0000000000000007
   Parameter[1]: ffffffff80070057
   Parameter[2]: 0000000000000071
Subcode: 0x7 FAST_FAIL_FATAL_APP_EXIT 

PROCESS_NAME:  ctfmon.exe

EXCEPTION_CODE_STR:  80070057

FAULTING_THREAD:  00005648

STACK_TEXT:  
00000088`1cb7d7e0 00007ffd`d79b1a8f     : 00000088`1cb7dff0 00007ffe`6b07c260 00000000`00000000 00007ffe`5fd1311d : KERNELBASE!RaiseFailFastException+0x152
00000088`1cb7ddc0 00007ffd`d79b1b8e     : 00000088`1cb7df10 00000000`00000071 0000a576`4bc4f6c5 00000000`00000000 : InputService!wil::details::WilDynamicLoadRaiseFailFastException+0x5f
00000088`1cb7ddf0 00007ffd`d79b1b64     : 00000000`00000000 00000000`00000001 00000088`1cb7deb0 00000088`1cb7def0 : InputService!wil::details::WilRaiseFailFastException+0x22
00000088`1cb7de20 00007ffd`d79aaf53     : 00000088`1cb7f4b0 00000088`1cb7dff0 00000000`00000071 00007ffe`67cbcb64 : InputService!wil::details::WilFailFast+0xbc
00000088`1cb7def0 00007ffd`d79aaa58     : 00000000`00000000 00000000`00000000 00000000`00000000 000001b7`19346788 : InputService!wil::details::ReportFailure_NoReturn<3>+0x2df
00000088`1cb7f3f0 00007ffd`d79aac6b     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : InputService!wil::details::ReportFailure_Base<3,0>+0x30
00000088`1cb7f450 00007ffd`d79431e0     : 00000088`1cb7f590 00007ffe`5fd1311d 000001b7`19325340 00007ffd`d797d080 : InputService!wil::details::ReportFailure_Hr<3>+0x5f
00000088`1cb7f4d0 00007ffd`d794cce6     : 00000088`1cb7f5f0 00000088`1cb7f590 00007ffd`d794b750 00000088`1cb7f550 : InputService!wil::details::in1diag3::FailFast_Hr+0x18
00000088`1cb7f520 00007ffe`67cbcb64     : 00000088`1cb7f5f0 00007ffd`d794b750 00000000`00000000 00000088`1cb7fa70 : InputService!<lambda_e9c081f003eb6b2a1a472fadecf202ae>::operator()+0x2b2
00000088`1cb7f5a0 00007ffe`67cbc5de     : 000001b7`193199e0 00007ffd`d794b750 000001b7`193199e0 00007ffd`d794b750 : CoreMessaging!CFlat::SehSafe::Execute<<lambda_a81ff790741c2a62f2197c2561f5fe49> >+0x2c
00000088`1cb7f5d0 00007ffe`67cc9f2f     : 000001b7`19352a70 00000088`1cb7f648 00000000`00000000 000001b7`19352e30 : CoreMessaging!Microsoft::CoreUI::ActionCallback::ImportAdapter$+0xae
00000088`1cb7f610 00007ffe`67cc8383     : 000001b7`1934c400 00000000`00000001 000001b7`19325340 000001b7`1933eba0 : CoreMessaging!Microsoft::CoreUI::Dispatch::DeferredCall::Callback_Dispatch+0x2bf
00000088`1cb7f6d0 00007ffe`67cc8d0f     : 000001b7`00000007 000001b7`19344120 000001b7`19352bc0 000001b7`19344120 : CoreMessaging!Microsoft::CoreUI::Dispatch::DeferredCallDispatcher::Callback_OnDispatch+0x3a3
00000088`1cb7f780 00007ffe`67cc7b4b     : 00000000`00000000 000001b7`1933e930 00000000`00000001 00000000`00000000 : CoreMessaging!Microsoft::CoreUI::Dispatch::EventLoop::Callback_RunCoreLoop+0x36f
00000088`1cb7f890 00007ffe`67c82b71     : 000001b7`1933e930 000001b7`00000001 00000000`1933e901 00000000`00000000 : CoreMessaging!Microsoft::CoreUI::Dispatch::Win32EventLoopBridge::Callback_Run+0x5ab
00000088`1cb7f960 00007ffe`67c82aaf     : 000001b7`1933e930 000001b7`1933e930 000001b7`1934bbe0 00000000`00000000 : CoreMessaging!Microsoft::CoreUI::Dispatch::EventLoop::Callback_Run+0xa1
00000088`1cb7f9b0 00007ffe`67c94126     : 000001b7`193199e0 000001b7`1933e930 00000000`1cb7f880 00000088`00000004 : CoreMessaging!Microsoft::CoreUI::Messaging::MessageSession::InterfaceImplementation$::_Microsoft_CoreUI_IExportMessageSession::Dispatcher::Run+0x2f
00000088`1cb7f9e0 00007ffd`d794d36c     : 000001b7`193197a0 000001b7`193199e0 00000000`00000000 00000000`00000000 : CoreMessaging!Microsoft::CoreUI::IExportMessageSession::ExportAdapter$::Run+0x66
00000088`1cb7fa20 00007ffe`6cd0257d     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : InputService!AmbientLighting::AmbientLightingHost::LightingThreadProc+0x22c
00000088`1cb7fac0 00007ffe`6dc0aa58     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x1d
00000088`1cb7faf0 00000000`00000000     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x28


SYMBOL_NAME:  inputservice!<lambda_e9c081f003eb6b2a1a472fadecf202ae>::operator+2b2

MODULE_NAME: InputService

IMAGE_NAME:  InputService.dll

STACK_COMMAND:  ~14s ; .cxr ; kb

FAILURE_BUCKET_ID:  FAIL_FAST_FATAL_APP_EXIT_80070057_InputService.dll!_lambda_e9c081f003eb6b2a1a472fadecf202ae_::operator

OS_VERSION:  10.0.22621.1

BUILDLAB_STR:  ni_release

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

IMAGE_VERSION:  10.0.22621.2506

FAILURE_ID_HASH:  {244d2e09-2701-2fb9-7de3-c7110c080dac}

Followup:     MachineOwner
---------

0:014> .exr -1
ExceptionAddress: 00007ffdd794cce6 (InputService!<lambda_e9c081f003eb6b2a1a472fadecf202ae>::operator()+0x00000000000002b2)
   ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
  ExceptionFlags: 00000001
NumberParameters: 3
   Parameter[0]: 0000000000000007
   Parameter[1]: ffffffff80070057
   Parameter[2]: 0000000000000071
Subcode: 0x7 FAST_FAIL_FATAL_APP_EXIT
@bluearcher-bc commented on GitHub (Nov 26, 2023): Win11 2H23 (although I only updated to this build AFTER this issue started occurring) I really hate to latch on to this thread, but this seems to be where all the important knowledge on this topic lies. As of a week or two ago, my ctfmon.exe has started crashing constantly, potentially every time I try to type somewhere it is required. At a minimum I have issues inputting text in places like start menu, settings, calculator, Unigram, etc. I have been unable to stabilize ctfmon.exe using numerous techniques described in this page and elsewhere. A lot of the conventional wisdom on this process seems to originate from Win10 days when it genuinely was not required and many people disabled it. Long story short, where can I go for more detailed help figuring out why this process constantly crashes? I have attached the output of WinDbg on a mini dump of a recent crash. ``` Microsoft (R) Windows Debugger Version 10.0.25921.1001 AMD64 Copyright (c) Microsoft Corporation. All rights reserved. Loading Dump File [C:\Users\<snip>\AppData\Local\CrashDumps\ctfmon.exe.26676.dmp] User Mini Dump File: Only registers, stack and portions of memory are available ************* Path validation summary ************** Response Time (ms) Location Deferred srv* Symbol search path is: srv* Executable search path is: Windows 10 Version 22631 MP (6 procs) Free x64 Product: WinNt, suite: SingleUserTS Edition build lab: 22621.1.amd64fre.ni_release.220506-1250 Debug session time: Sun Nov 26 11:57:27.000 2023 (UTC - 5:00) System Uptime: not available Process Uptime: 0 days 0:00:01.000 ................................................... This dump file has an exception of interest stored in it. The stored exception information can be accessed via .ecxr. (6834.5648): Security check failure or stack buffer overrun - code c0000409 (first/second chance not available) Subcode: 0x7 FAST_FAIL_FATAL_APP_EXIT For analysis of this file, run !analyze -v KERNELBASE!RaiseFailFastException+0x152: 00007ffe`6b07c3b2 0f1f440000 nop dword ptr [rax+rax] 0:014> !analyze -v ******************************************************************************* * * * Exception Analysis * * * ******************************************************************************* *** WARNING: Check Image - Checksum mismatch - Dump: 0x4a49e7, File: 0x4a4b8d - C:\ProgramData\Dbg\sym\InputService.dll\2229545C4bb000\InputService.dll DEBUG_FLR_EXCEPTION_CODE(80070057) and the ".exr -1" ExceptionCode(c0000409) don't match KEY_VALUES_STRING: 1 Key : Analysis.CPU.mSec Value: 921 Key : Analysis.Elapsed.mSec Value: 938 Key : Analysis.IO.Other.Mb Value: 0 Key : Analysis.IO.Read.Mb Value: 0 Key : Analysis.IO.Write.Mb Value: 0 Key : Analysis.Init.CPU.mSec Value: 171 Key : Analysis.Init.Elapsed.mSec Value: 22137 Key : Analysis.Memory.CommitPeak.Mb Value: 123 Key : FailFast.Name Value: FATAL_APP_EXIT Key : FailFast.Type Value: 7 Key : Failure.Bucket Value: FAIL_FAST_FATAL_APP_EXIT_80070057_InputService.dll!_lambda_e9c081f003eb6b2a1a472fadecf202ae_::operator Key : Failure.Hash Value: {244d2e09-2701-2fb9-7de3-c7110c080dac} Key : Timeline.Process.Start.DeltaSec Value: 1 Key : WER.OS.Branch Value: ni_release Key : WER.OS.Version Value: 10.0.22621.1 Key : WER.Process.Version Value: 10.0.22621.1 FILE_IN_CAB: ctfmon.exe.26676.dmp NTGLOBALFLAG: 0 APPLICATION_VERIFIER_FLAGS: 0 CONTEXT: (.ecxr) rax=000000881cb7d8c0 rbx=000000881cb7de40 rcx=000000881cb7d8c0 rdx=000000881cb7dd70 rsi=000000881cb7de40 rdi=000000881cb7d8c0 rip=00007ffe6b07c3b2 rsp=000000881cb7d7e0 rbp=0000000000000001 r8=0000000000000000 r9=000000881cb7dd20 r10=00000fffcd60f84d r11=0000000000002000 r12=0000000000000001 r13=0000000000000000 r14=0000000000000000 r15=00007ffdd794cce6 iopl=0 nv up ei pl nz na po nc cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000204 KERNELBASE!RaiseFailFastException+0x152: 00007ffe`6b07c3b2 0f1f440000 nop dword ptr [rax+rax] Resetting default scope EXCEPTION_RECORD: (.exr -1) ExceptionAddress: 00007ffdd794cce6 (InputService!<lambda_e9c081f003eb6b2a1a472fadecf202ae>::operator()+0x00000000000002b2) ExceptionCode: c0000409 (Security check failure or stack buffer overrun) ExceptionFlags: 00000001 NumberParameters: 3 Parameter[0]: 0000000000000007 Parameter[1]: ffffffff80070057 Parameter[2]: 0000000000000071 Subcode: 0x7 FAST_FAIL_FATAL_APP_EXIT PROCESS_NAME: ctfmon.exe EXCEPTION_CODE_STR: 80070057 FAULTING_THREAD: 00005648 STACK_TEXT: 00000088`1cb7d7e0 00007ffd`d79b1a8f : 00000088`1cb7dff0 00007ffe`6b07c260 00000000`00000000 00007ffe`5fd1311d : KERNELBASE!RaiseFailFastException+0x152 00000088`1cb7ddc0 00007ffd`d79b1b8e : 00000088`1cb7df10 00000000`00000071 0000a576`4bc4f6c5 00000000`00000000 : InputService!wil::details::WilDynamicLoadRaiseFailFastException+0x5f 00000088`1cb7ddf0 00007ffd`d79b1b64 : 00000000`00000000 00000000`00000001 00000088`1cb7deb0 00000088`1cb7def0 : InputService!wil::details::WilRaiseFailFastException+0x22 00000088`1cb7de20 00007ffd`d79aaf53 : 00000088`1cb7f4b0 00000088`1cb7dff0 00000000`00000071 00007ffe`67cbcb64 : InputService!wil::details::WilFailFast+0xbc 00000088`1cb7def0 00007ffd`d79aaa58 : 00000000`00000000 00000000`00000000 00000000`00000000 000001b7`19346788 : InputService!wil::details::ReportFailure_NoReturn<3>+0x2df 00000088`1cb7f3f0 00007ffd`d79aac6b : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : InputService!wil::details::ReportFailure_Base<3,0>+0x30 00000088`1cb7f450 00007ffd`d79431e0 : 00000088`1cb7f590 00007ffe`5fd1311d 000001b7`19325340 00007ffd`d797d080 : InputService!wil::details::ReportFailure_Hr<3>+0x5f 00000088`1cb7f4d0 00007ffd`d794cce6 : 00000088`1cb7f5f0 00000088`1cb7f590 00007ffd`d794b750 00000088`1cb7f550 : InputService!wil::details::in1diag3::FailFast_Hr+0x18 00000088`1cb7f520 00007ffe`67cbcb64 : 00000088`1cb7f5f0 00007ffd`d794b750 00000000`00000000 00000088`1cb7fa70 : InputService!<lambda_e9c081f003eb6b2a1a472fadecf202ae>::operator()+0x2b2 00000088`1cb7f5a0 00007ffe`67cbc5de : 000001b7`193199e0 00007ffd`d794b750 000001b7`193199e0 00007ffd`d794b750 : CoreMessaging!CFlat::SehSafe::Execute<<lambda_a81ff790741c2a62f2197c2561f5fe49> >+0x2c 00000088`1cb7f5d0 00007ffe`67cc9f2f : 000001b7`19352a70 00000088`1cb7f648 00000000`00000000 000001b7`19352e30 : CoreMessaging!Microsoft::CoreUI::ActionCallback::ImportAdapter$+0xae 00000088`1cb7f610 00007ffe`67cc8383 : 000001b7`1934c400 00000000`00000001 000001b7`19325340 000001b7`1933eba0 : CoreMessaging!Microsoft::CoreUI::Dispatch::DeferredCall::Callback_Dispatch+0x2bf 00000088`1cb7f6d0 00007ffe`67cc8d0f : 000001b7`00000007 000001b7`19344120 000001b7`19352bc0 000001b7`19344120 : CoreMessaging!Microsoft::CoreUI::Dispatch::DeferredCallDispatcher::Callback_OnDispatch+0x3a3 00000088`1cb7f780 00007ffe`67cc7b4b : 00000000`00000000 000001b7`1933e930 00000000`00000001 00000000`00000000 : CoreMessaging!Microsoft::CoreUI::Dispatch::EventLoop::Callback_RunCoreLoop+0x36f 00000088`1cb7f890 00007ffe`67c82b71 : 000001b7`1933e930 000001b7`00000001 00000000`1933e901 00000000`00000000 : CoreMessaging!Microsoft::CoreUI::Dispatch::Win32EventLoopBridge::Callback_Run+0x5ab 00000088`1cb7f960 00007ffe`67c82aaf : 000001b7`1933e930 000001b7`1933e930 000001b7`1934bbe0 00000000`00000000 : CoreMessaging!Microsoft::CoreUI::Dispatch::EventLoop::Callback_Run+0xa1 00000088`1cb7f9b0 00007ffe`67c94126 : 000001b7`193199e0 000001b7`1933e930 00000000`1cb7f880 00000088`00000004 : CoreMessaging!Microsoft::CoreUI::Messaging::MessageSession::InterfaceImplementation$::_Microsoft_CoreUI_IExportMessageSession::Dispatcher::Run+0x2f 00000088`1cb7f9e0 00007ffd`d794d36c : 000001b7`193197a0 000001b7`193199e0 00000000`00000000 00000000`00000000 : CoreMessaging!Microsoft::CoreUI::IExportMessageSession::ExportAdapter$::Run+0x66 00000088`1cb7fa20 00007ffe`6cd0257d : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : InputService!AmbientLighting::AmbientLightingHost::LightingThreadProc+0x22c 00000088`1cb7fac0 00007ffe`6dc0aa58 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0x1d 00000088`1cb7faf0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x28 SYMBOL_NAME: inputservice!<lambda_e9c081f003eb6b2a1a472fadecf202ae>::operator+2b2 MODULE_NAME: InputService IMAGE_NAME: InputService.dll STACK_COMMAND: ~14s ; .cxr ; kb FAILURE_BUCKET_ID: FAIL_FAST_FATAL_APP_EXIT_80070057_InputService.dll!_lambda_e9c081f003eb6b2a1a472fadecf202ae_::operator OS_VERSION: 10.0.22621.1 BUILDLAB_STR: ni_release OSPLATFORM_TYPE: x64 OSNAME: Windows 10 IMAGE_VERSION: 10.0.22621.2506 FAILURE_ID_HASH: {244d2e09-2701-2fb9-7de3-c7110c080dac} Followup: MachineOwner --------- 0:014> .exr -1 ExceptionAddress: 00007ffdd794cce6 (InputService!<lambda_e9c081f003eb6b2a1a472fadecf202ae>::operator()+0x00000000000002b2) ExceptionCode: c0000409 (Security check failure or stack buffer overrun) ExceptionFlags: 00000001 NumberParameters: 3 Parameter[0]: 0000000000000007 Parameter[1]: ffffffff80070057 Parameter[2]: 0000000000000071 Subcode: 0x7 FAST_FAIL_FATAL_APP_EXIT ```
claunia commented 2026-01-31 03:02:07 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Nov 27, 2023):

@BlueArcherX You're not the first person hitting this issue and it started occurring since about 10 days ago. You should file an issue on the Feedback Hub and attach your dump to it. I'm not entirely sure what category ctfmon falls under but I bet it's "Input and Language > Text Input". You can mention that it's most likely Watson bucket 60581292-caf7-eac1-65e8-6883bfb50923. Other Microsoft employees will know what that means. 🙂 If you link it here I can check that it's going through the system correctly.
I believe the issue occurs due to the ambient lighting support for keyboards that was added to Win 11 recently.

@lhecker commented on GitHub (Nov 27, 2023): @BlueArcherX You're not the first person hitting this issue and it started occurring since about 10 days ago. You should file an issue on the Feedback Hub and attach your dump to it. I'm not entirely sure what category ctfmon falls under but I bet it's "Input and Language > Text Input". You can mention that it's most likely Watson bucket `60581292-caf7-eac1-65e8-6883bfb50923`. Other Microsoft employees will know what that means. 🙂 If you link it here I can check that it's going through the system correctly. I believe the issue occurs due to the ambient lighting support for keyboards that was added to Win 11 recently.
claunia commented 2026-01-31 03:02:07 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Nov 27, 2023):

Alas, that particular failure hash (244d2e09-2701-2fb9-7de3-c7110c080dac) doesn't seem to show up on the backend. However, bucket 60581292-caf7-eac1-65e8-6883bfb50923 does, and that's linked to a bunch of bugs. MSFT:45105418 looks like it's got the most traction.

Hits started spiking on 11/17, right about the same time as the holidays. I'm guessing there haven't been many folks in to take a look quite yet. I reached out and I'll let you know if I hear anything.

@ebadger as an FYI

@zadjii-msft commented on GitHub (Nov 27, 2023): Alas, that particular failure hash (`244d2e09-2701-2fb9-7de3-c7110c080dac`) doesn't seem to show up on the backend. However, bucket `60581292-caf7-eac1-65e8-6883bfb50923` does, and that's linked to a bunch of bugs. MSFT:45105418 looks like it's got the most traction. Hits started spiking on 11/17, right about the same time as the holidays. I'm guessing there haven't been many folks in to take a look quite yet. I reached out and I'll let you know if I hear anything. @ebadger as an FYI
claunia commented 2026-01-31 03:02:08 +00:00
Author
Owner
Copy Link

@bluearcher-bc commented on GitHub (Nov 27, 2023):

Thanks all, this makes me feel a lot better. I thought I was going crazy.

For what it's worth, last night I got fed up after so many hours of working on it, and did a Windows recovery reinstall from a MCT bootable USB (keeping apps and data) and it fixed the issue. No amount of online or offline SFC or DISM commands had any success.

@bluearcher-bc commented on GitHub (Nov 27, 2023): Thanks all, this makes me feel a lot better. I thought I was going crazy. For what it's worth, last night I got fed up after so many hours of working on it, and did a Windows recovery reinstall from a MCT bootable USB (keeping apps and data) and it fixed the issue. No amount of online or offline SFC or DISM commands had any success.
claunia commented 2026-01-31 03:02:08 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Feb 23, 2024):

(looping back: that above bug got fixed in os.2020!10329723. It'll probably roll out over the next month)

@zadjii-msft commented on GitHub (Feb 23, 2024): (looping back: that above bug got fixed in os.2020!10329723. It'll probably roll out over the next month)
claunia commented 2026-01-31 03:02:08 +00:00
Author
Owner
Copy Link

@tyduckMSFT commented on GitHub (Feb 28, 2024):

Until the bug fix does roll out, a workaround would be to turn off the following toggle in Settings:
Personalization -> Dynamic Lighting -> "Use Dynamic Lighting on my devices"

@tyduckMSFT commented on GitHub (Feb 28, 2024): Until the bug fix does roll out, a workaround would be to turn off the following toggle in Settings: Personalization -> Dynamic Lighting -> "Use Dynamic Lighting on my devices"
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Issue-Question Needs-Tag-Fix Product-Terminal
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#11946
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?