Malfunction custom keyboard DLL & Windows Search

Question

Malfunction custom keyboard DLL & Windows Search

François T 20

Hello,

I built a keyboard driver using Visual Studio and the official Windows driver samples. The DLL works perfectly regarding the keyboard and its behavior.

The problem is that when this keyboard is selected alone, Windows Search malfunctions and indexing stops. Even after restarting it manually, rebooting the machine breaks everything again.

When I load a native keyboard and this new keyboard together, the problem disappears. However, I would prefer to have only one keyboard selected.

I'm on Windows 11 Home H2 WDK 7600.16385.1. The keyboard was registered through an additional registry key and linked to the 40C code for French (France), in the same way the Microsoft Keyboard Layout Manager installer does. The event log shows that Windows Search is unable to start (but I’m not an expert). I tested permissions using icacls for Windows Search, but without success.

How can I fix this undesirable side effect?

Thank you!

0 comments

1 answer

Your answer

Answer 1

Here’s a draft response you can post:

Thanks for the details. A couple of things stand out before treating this as a Windows Search permissions issue. First, can you confirm the exact Windows version/build from winver? “Windows 11 Home H2” is ambiguous — it could mean 22H2, 23H2, 24H2, etc. Second, WDK 7600.16385.1 is the Windows 7-era WDK. That is a significant mismatch for Windows 11 and is not a configuration I would recommend for building or validating a keyboard layout DLL on Windows 11. Please rebuild and test the layout using the current supported WDK/SDK toolchain for Windows 11: https://learn.microsoft.com/windows-hardware/drivers/download-the-wdk Also, make sure the custom layout is registered as its own layout and not replacing or overloading the built-in French layout entry. In particular, avoid modifying the built-in 0000040c French layout directly. Use a distinct KLID for the custom layout, keep a standard Microsoft keyboard layout installed as a fallback during testing, and verify the Keyboard Layouts registry entries point to a valid signed/accessible DLL in the correct system directory. Since Windows Search fails only when this layout is the only selected keyboard, the next useful data would be:

The exact Windows build from winver

The full Windows Search event log error, including faulting module / HRESULT

The custom keyboard layout registry entries

Whether the issue reproduces after rebuilding with a current Windows 11 WDK/SDK I would not focus on icacls first unless the event log explicitly shows an access-denied failure. The old WDK version and layout registration approach are bigger red flags here.