Microsoft Pinyin (ChsIME.exe) on Windows 11 25H2: a second IME instance accumulates kernel-mode CPU close to one core; historical samples show persistent TSF connect failures

Summary

On Windows 11 25H2 (Build 26200.9711), ChsIME.exe (Microsoft Pinyin IME) is registered as an out-of-process COM local server: CImeServerChs, under two CLSIDs, each with a LocalServer32 subkey whose default value points at C:\Windows\System32\InputMethod\CHS\ChsIME.exe. In the registry views we queried, neither CLSID has an AppID value, and neither has a LocalService or LocalSystem value. RunAs is configured on an AppID key rather than on a CLSID key, so no RunAs setting applies to an activation that resolves through these CLSIDs. We did not enumerate AppID keys elsewhere in the registry, so this is not a claim that no such key exists.

Impact observed on our test machine. On 2026-09-07 an affected instance ran for about four hours, with the lid closed for about two of them; the case record for that incident notes sustained high fan speed, and battery charge fell from 100% (29,032 mWh) to 15% (4,499 mWh) between 21:58 and 23:43. A later instance (activated 2026-09-20, captured 2026-09-22) had accumulated about 47.3 hours of kernel-mode CPU over 51.7 hours of uptime when it was captured. Over the 31-day monitoring window, some instances ended only after manual intervention. Separately, in controlled activation attempts on 2026-09-22, the resulting instance could neither be opened nor terminated by our non-elevated test process. We have not isolated the mechanism of the battery drain; the CPU accounting is the part we can quantify.

On our test machine we observed two ChsIME.exe instances running side by side with the same parent process, svchost.exe (PID 1240). One had 78 threads; the other had 2. The second accumulates CPU time almost entirely in kernel mode: one affected instance took 69.925 hours of kernel-mode CPU over 75.51 hours of wall-clock uptime (~92.6% of one core).

Separately, September captures from an earlier affected instance recorded repeated TSF connection failures on the monitor port \BaseNamedObjects\msctf.serverDefault1. We have not established that the October instance followed the same failure path.

We do not know which process requested the activation, and we have not established the exact failure status returned by the connect attempt. Both are listed below as open questions rather than findings.

Environment

• Windows 11 25H2, Build 26200.9711. Note: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion still reports ProductName = Windows 10 Enterprise; the Windows 11 / 25H2 identification is based on DisplayVersion = 25H2 with CurrentBuild = 26200 and UBR = 9711 (re-measured 2026-10-26).
• C:\Windows\System32\InputMethod\CHS\ChsIME.exe, file version 10.0.26100.9278, owner NT SERVICE\TrustedInstaller, Authenticode status Valid — re-measured 2026-10-26 (signer subject not re-captured in this record).
• The observations concern the single interactive user session, with Chinese (Simplified) IME installed. Desktop affiliation at failure time was not recorded.
• TextInputManagementService (the renamed Touch Keyboard / Handwriting Panel service), status Running, startup type Automatic — re-measured 2026-10-26.

Observed behavior

Retry cadence and Start→Failed intervals are wall-clock measurements, not CPU costs. Their arithmetic product (≈0.994, dimensionless) must not be read as CPU time, and the earlier "more than one core" reading is incorrect. Process accounting establishes the high cumulative kernel CPU usage; the captured stack identifies a sampled call path, not its share of CPU consumption. The ~92.6% figure is cumulative kernel CPU time divided by process age: it is a lifetime average, not evidence that the process was busy in every interval.

Evidence inventory (capture dates shown; historical version coverage incomplete)

The historical mechanism evidence has not been verified against the October build.

Note on A3a — same integrity level, different outcome

On 2026-09-07 the spinning instance and our probe process were both at Medium (the probe was run after midnight, on 2026-09-08). The probe connected to the monitor port four times in a row, while the affected instance did not. This is the single most informative comparison we have: it means the difference between "connects" and "does not connect" is not explained by integrity level alone.

We previously assumed a security-context rejection. That assumption is withdrawn insofar as it rests on integrity level alone; other differences in security context have not been excluded. We still do not know the actual failure status of the affected instance's connect calls; the ETW failure events carry no status payload.

What we did not establish

1. Which process (or component) requested the activation.
2. The exact status returned when connecting to msctf.serverDefault1; our failure events carry no status payload.
3. Whether the TSF monitor rejects the connection on integrity/UIAccess grounds, on some other security check, or for another reason. Note that a probe at the same integrity level connected successfully, so a pure integrity-level rule is not supported.
4. Whether the system's decision to create a second instance instead of reusing the long-lived one is a documented rule, and what inputs it uses.
5. A stable reproduction of the natural failure: the controlled attempts did not reproduce the high-CPU symptom. A bare COM activation did not produce a spinning instance, and in the GUI attempt the resulting instance could not be opened or terminated by the non-elevated test process; its integrity level was not directly established.

Questions for Microsoft

Primary request: please investigate the reported high kernel-mode CPU usage in ChsIME.exe, and tell us which supported diagnostics are needed to determine the cause.

1. What is the intended activation and security context for the CImeServerChs local server? Should a medium-integrity caller be able to activate a functional instance, and if not, what is the expected outcome for that caller?
2. What determines whether an existing ChsIME.exe instance is reused or a new one is created? We observe two instances with the same parent; we do not know which rule produced that.
3. In the retry path (symbolized as msctf!CAlpcPort::Open → NtAlpcConnectPortEx), is a persistent connect failure expected to be bounded? In msctf 10.0.26100.8875 and the code paths we followed, we did not find an explicit increasing backoff or a retry cap; the observed behaviour is a sustained high-frequency failure loop.
4. Which diagnostics would let us determine (a) the activating client and (b) the actual connect failure status? Is there a supported channel to submit raw dumps and ETW traces?
5. Is terminating the affected instance the recommended workaround, or is there a supported mitigation?
6. Could a desktop switch, or an application disabling and then re-enabling the IME, affect CImeServerChs initialization or its connection to the monitor? Which supported diagnostics distinguish desktop/session state from a security-context rejection? We have not recorded the desktop affiliation at failure time.