DISCUSSION: Continued commentary about the touch keyboard service

[levicki]

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.

[DHowett]

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 #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]

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.

[levicki]

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

[zadjii-msft]

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

[levicki]

Yes, of course I can:

[ebadger]

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

[levicki]

@ebadger

[ebadger]

@ebadger

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

[levicki]

Microsoft Windows [Version 10.0.19042.685]

[ebadger]

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

[levicki]

@ebadger Sure

[levicki]

[ebadger]

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.

[levicki]

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]

@ebadger @zadjii-msft

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

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.

[piscisaureus]

[ebadger]

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

[DHowett]

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

[piscisaureus]

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

[ebadger]

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

[levicki]

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

[dcs619]

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.

[amard33p]

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.

[LinuxOnTheDesktop]

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

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.

[KalleOlaviNiemitalo]

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.

[synap5e]

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.

[bluearcher-bc]

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 

[lhecker]

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

[zadjii-msft]

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

[bluearcher-bc]

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.

[zadjii-msft]

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

[tyduckMSFT]

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"