このときはNVIDIAドライバが一番怪しかったけど、結果的に問題は解消したので、iGPUも無効のままにしてあったんだ。
さて、Windows Terminalのクラッシュ問題対策に、iGPUを有効にすべきか否か。青画面が復活したら嫌だしなぁ。

やっぱMSIMEだとクラッシュしないな。ATOKの問題か…

確かにWindows TeminalでATOKで日本語入力すると、最近なんか重いんだよ。
まあこの組み合わせを使ってる人類は皆無だろうから、この問題は直らないだろな。やれやれ。

iGPUにしてもダメだった。というか、iGPUだとIME関係なく重くて使えん。

JustSystemのサポートに問い合わせるかなぁ。面倒だなぁ。

というより私がこの問題に気づいたのは10/26のことだし、ATOKエンジンのアップデートは2月だし、Geforceドライバは前後で更新してないし、となると10/24リリースのWindows Terminal v1.21.2911.0がやっぱりおかしいんじゃないか？

ATOKのサポート、電話しかないのか…電話でWindows Terminalでの不具合を説明するの？

Windows Terminal 1.20.11781.0では問題が発生しないことを確認。1.21からATOKで不具合が起きるようになったんだな。さて、どうしますかね…

1.21ではレンダリングエンジンがデフォルトでAtlasEngineになったんだけど、ATOKとの相性が良くないんだろうなぁ。それにしては、1.20のときAtlasEngine有効にしても大丈夫だったけどな。

仕方がないので、Windows TerminalだけMSIMEを使うことにする。ただ、知らなかったけど新MSIMEっていまだにキーバインドすら設定できないのか。旧バージョンに今はまだ戻せるみたいだけど、新MSIMEできて何年経ってるんだって話よな。

Windows Terminal、旧MSIMEだとATOKと同じ不具合が発生するやんけ…

つまり、人類は皆、新MSIMEを使っているということか。それかWindows Terminalで日本語入力する人類はほとんど居ないだけなのかもしれないが。

1.22previewでも治ってないや。
これはWindows Terminalの方にissue上げるのが正攻法かもしれんな。ATOKで起きる不具合はちょっと報告が憚られるが、旧MSIMEで発生するなら、開発者が再現させることも可能であろう。（1.21にはIMEに関する改善も含まれてるわけだしね）

Windows Terminal 1.21以上で旧MSIMEやATOKをクラッシュさせる最短手順も確立した。

IMEオン状態で、
A→A→[space]→A
これが一番早いと思います。

要は、確定をEnterキーで行えばクラッシュしないが、Enter以外のキーで確定しつつ、次の文字を入力するのがNGということ。

未確定文字列を確定文字列にする際、Enterキーの押下が何らかのトリガーになっているとか、未確定文字列→確定文字列化と、新しく未確定文字列が描画される処理が同時に発生することがまずいのか。ともかくWindows Terminal側に何らかの問題がある。

で、これAutoHotKeyでアドホックに回避する方法を思いついてしまったのだけど、それで自分だけ幸せになるのは許されるかなｗ

出来ると思ったんだけど、Windows Terminalでは未確定文字列が表示されている領域のクラス名が取れないので無理だった。
まあChromeとかでも取れないんで、IMEが入力フィールドに統合？されてると無理なんだろうな。

再現手順を英語圏向けに一から説明するのがめんどくさいので、OSSにissueは結局いつも立てないし、今回も立てないと思う。日本語固有の問題じゃなかったらそうでもないんだけどな。