Custom Keyboard Layouts in Windows 11 No Longer Works

Root cause analysis + a working workaround (tested on 26200.9168 / 25H2)

We hit the same "Unavailable input method" wall with custom KLID layouts and ran a full experiment matrix on Windows 11 25H2 (build 26200.9168). Findings:

Why it shows "Unavailable input method": The Settings page (Language options → Keyboards) resolves keyboard entry display names only from the built-in layout tables (input.dll / NLS). Any custom KLID (the a0000xxx namespace MSKLC generates) is outside those tables, so Settings falls back to "Unavailable input method" — regardless of:

• Layout Text being set correctly

Layout Display Name being set (plain string or indirect string)

The entry being written through the modern API channel (Get-WinUserLanguageList / Set-WinUserLanguageList round-trip — which, notably, does accept and preserve custom KLIDs)

Meanwhile the tray indicator, the Win+Space input switcher, and actual typing all work correctly with the custom layout. The defect is purely in Settings' name-resolution path.

Additional data points from our experiments:

Removing Layout Id from the layout registration does NOT fix the Settings display — it actually breaks layout loading (the layout silently disappears from the switcher). Layout Id is required.

On 24H2+ the per-language "Add a keyboard" list is curated: for zh-CN it only offers Microsoft Pinyin / Microsoft Wubi. The plain US keyboard is no longer offered, and custom KLID layouts are never enumerated. For users who need a bare US layout under the Chinese language (e.g., gaming: zero key interception, no IME global hotkeys, no candidate popup in fullscreen games), the Settings UI path is fully closed — registry is the only way.

The legacy d0000804 preload-substitute chain stopped having any effect on the tray indicator since 24H2.

Workaround that works (functional surfaces): Register a custom KLID (e.g. a0000804: Layout File = KBDUS.DLL, Layout Text = <same as language display name>, Layout Id = 0ae1), then use it as the language's keyboard entry (0804:a0000804 in the user profile). Tray/switcher/typing are all correct. Accept the cosmetic "Unavailable input method" in Settings until this is fixed.

We'd appreciate the Settings team either resolving custom layout names from Layout Text/Layout Display Name, or restoring custom layouts (and the plain US keyboard for non-Latin languages) to the per-language add list.Root cause analysis + a working workaround (tested on 26200.9168 / 25H2)

We hit the same "Unavailable input method" wall with custom KLID layouts and ran a full experiment matrix on Windows 11 25H2 (build 26200.9168). Findings:

Why it shows "Unavailable input method": The Settings page (Language options → Keyboards) resolves keyboard entry display names only from the built-in layout tables (input.dll / NLS). Any custom KLID (the a0000xxx namespace MSKLC generates) is outside those tables, so Settings falls back to "Unavailable input method" — regardless of:

Layout Text being set correctly

Layout Display Name being set (plain string or indirect string)

The entry being written through the modern API channel (Get-WinUserLanguageList / Set-WinUserLanguageList round-trip — which, notably, does accept and preserve custom KLIDs)

Meanwhile the tray indicator, the Win+Space input switcher, and actual typing all work correctly with the custom layout. The defect is purely in Settings' name-resolution path.

Additional data points from our experiments:

Removing Layout Id from the layout registration does NOT fix the Settings display — it actually breaks layout loading (the layout silently disappears from the switcher). Layout Id is required.

On 24H2+ the per-language "Add a keyboard" list is curated: for zh-CN it only offers Microsoft Pinyin / Microsoft Wubi. The plain US keyboard is no longer offered, and custom KLID layouts are never enumerated. For users who need a bare US layout under the Chinese language (e.g., gaming: zero key interception, no IME global hotkeys, no candidate popup in fullscreen games), the Settings UI path is fully closed — registry is the only way.

The legacy d0000804 preload-substitute chain stopped having any effect on the tray indicator since 24H2.

Workaround that works (functional surfaces): Register a custom KLID (e.g. a0000804: Layout File = KBDUS.DLL, Layout Text = <same as language display name>, Layout Id = 0ae1), then use it as the language's keyboard entry (0804:a0000804 in the user profile). Tray/switcher/typing are all correct. Accept the cosmetic "Unavailable input method" in Settings until this is fixed.

We'd appreciate the Settings team either resolving custom layout names from Layout Text/Layout Display Name, or restoring custom layouts (and the plain US keyboard for non-Latin languages) to the per-language add list.