Compile a keyboard layout with Visual Studio

Question

Compile a keyboard layout with Visual Studio

François T 20

Hello all,

I created a custom keyboard layout for my own usage. I edited the usual keyboard files (kbdxx.c, kbdxx.def, kbdxx.rc, kbdxx.h and sources) and added the others files (makefile and makefile.inc) based on WDK samples in a folder. I installed an old standalone version of Windows Driver Kits (https://download.microsoft.com/download/4/a/2/4a25c7d5-efbe-4182-b6a9-ae6850409a78/GRMWDK_EN_7600_1.ISO) and used the build command into the x64 Checked Build Environment console after locating it into my layout folder. It worked well and the produced layout dll is operational and well accepted by my Windows 11 OS. I therefore conclude that my files are OK.

To be honest, I wanted to use a more modern way. I tried too many times to do exactly the same thing through Visual Studio (2022 and even 2026 but given up due to the lack of helpful documentation), with the installed WDK module.

I added my keyboard files (kbdxx.c, kbdxx.def, kbdxx.rc, kbdxx.h) in my project, and saw that VS uploaded the Reference files (including kbd.h and winuser.h). I was then full of hope. I compiled but in vain.

I tried to uncheck the precompiled header option and to force "c" compilation. I also tried to add the 3 other files from the WDK (makefile, makefile.inc and my customed version of sources) to my project. Alas, even if a dll is produced, it never worked. Oddly, the dll produced this is quite bigger in size than the other one (18ko vs 10ko), don't know if it could help understanding the issue.

I'm not very used to Visual Studio, so I suspect I'm not setting it the right way up. Has anyone a step-by-step protocol to be sure to produce a clean dll for Windows x64 by using the kbdxx.c & co files?

Many thanks!

Answer accepted by question author

1 additional answer

Your answer

Answer 1

Tom Tran (WICLOUD CORPORATION) 4,580 Microsoft External Staff Moderator

Hi @François T ,

Based on what you described, your layout tables are likely correct. The key signal is that the same sources produce a working layout when built with the legacy WDK build.exe flow. In cases like this, the issue most often comes down to how the DLL is being produced in Visual Studio, rather than the table content itself.

A keyboard layout DLL is not the same as a generic “New DLL Project” in Visual Studio. Microsoft provides dedicated keyboard layout samples that are preconfigured to generate the expected binary shape. The documentation specifically instructs opening kbd.sln under the WDK src\input\layout folder and building from there using Visual Studio or MSBuild ([Microsoft Learn][1]).

Because of this, having KbdLayerDescriptor present in the source is necessary, but it does not by itself guarantee that the final DLL matches what Windows expects.

Perhaps you could try these suggestions:

1. Build a sample unchanged first Open the WDK keyboard layout sample solution:

…\src\input\layout\kbd.sln

Build one of the stock layouts (for example kbdus). This confirms your Visual Studio + WDK environment is producing a valid layout DLL.

Reference: https://learn.microsoft.com/en-us/samples/microsoft/windows-driver-samples/keyboard-layout-samples/

2. Verify the export table of your DLL

After building your custom DLL, run:

dumpbin /exports yourdll.dll

You should see KbdLayerDescriptor exported. If it is missing or differs from the sample build, Windows may not activate the layout correctly.

3. Check how your project was created

If your current project started from a generic DLL template, Visual Studio could introduce default runtime behavior unless carefully configured. The most reliable approach is to clone or modify an existing WDK keyboard sample project rather than building from a blank DLL template.

Also, if you are testing with Visual Studio 2026, try switching to Visual Studio 2022 for WDK work. Microsoft currently states that the WDK has not been validated with Visual Studio 2026 and recommends continuing with Visual Studio 2022.Reference: https://learn.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk#:~:text=Don%27t%20use%20Visual,supported%20by%20WDK.

Hope this helps! If you have any questions, please feel free to comment. I'll be happy to assist!

François T 20 Reputation points

2026-02-24T15:24:53.51+00:00

Hello Tom!

Thank you for your answer, it is really helpful!

I admit I didn't use the provided kbd.sln from the WDK. I just tried to produce a kbd without changing anything and another one with just a character switch.

I tested both dll (by copying them in system32 and changing the registry dll link for an existing layout. While trying to add this layout in the language settings, it made the setting windows to crash… so I suspect it didn't go well :(
Tom Tran (WICLOUD CORPORATION) 4,580 Reputation points Microsoft External Staff Moderator

2026-02-25T07:39:34.56+00:00

Hi @François T ,

Thank you for the update!

If even the untouched sample built in Visual Studio causes Settings to crash, then the problem is almost certainly not your keyboard layout itself. It points more toward how Visual Studio is building the DLL.

Keyboard layout DLLs are a bit unusual. They aren’t meant to behave like normal Windows DLLs, they’re supposed to be very small and simple. If Visual Studio builds it like a regular DLL, it can add extra startup code that Windows doesn’t expect for keyboard layouts. That can lead to the kind of crash you’re seeing.

One thing worth checking is whether the project is set to build the DLL with no entry point (sometimes shown as /NOENTRY in the linker settings). That prevents Visual Studio from adding extra startup code.

Also, since you’re manually updating the registry to point to your DLL, it’s a good idea to reboot before each test, just to make sure Windows isn’t keeping anything cached from the previous build.

At this stage, the consistent crash with the stock sample strongly suggests a project configuration issue rather than a problem with your layout changes.
François T 20 Reputation points

2026-02-26T16:31:03.72+00:00

Thank you Tom

Your feedbacks are very useful and appreciated!

How do I check that VS is set-up with no entry? Is it a code line to add in a file or a parameter to manage?

Many thanks!
Tom Tran (WICLOUD CORPORATION) 4,580 Reputation points Microsoft External Staff Moderator

2026-03-02T04:07:34.95+00:00
Hi @François T ,

Sorry for the late response.

This isn’t something you add in your C code. It’s a linker setting in the project configuration.

Here’s how to check it in Visual Studio:

In Visual Studio, right‑click your project (in Solution Explorer) and choose Properties.

At the top, make sure you’re looking at the configuration you’re building (for example Release and x64).

In the left panel, go to Configuration Properties → Linker → Advanced.

Find No Entry Point and set it to Yes (/NOENTRY).

Click Apply, then OK, and rebuild.

Microsoft describes this setting here:

https://learn.microsoft.com/en-us/cpp/build/reference/noentry-no-entry-point?view=msvc-170

After rebuilding, if Windows still seems to behave like it’s using the old DLL, a reboot can help make sure you’re testing the updated file.
Tom Tran (WICLOUD CORPORATION) 4,580 Reputation points Microsoft External Staff Moderator

2026-03-04T07:57:18.0033333+00:00

Hi @François T ,

I'm just checking in to see if you have any questions, please feel free to comment below. I'll be happy to assist!
François T 20 Reputation points

2026-03-09T10:34:57.4933333+00:00

Thank you Tom and sorry for the late answer!

It seems working thanks to your advice 😊
Tom Tran (WICLOUD CORPORATION) 4,580 Reputation points Microsoft External Staff Moderator

2026-03-09T11:03:37.66+00:00

Hi @François T ,

I’m really glad to hear everything is working now! Thank you for your confirmation.

If you found my assistance helpful or informative, I would greatly appreciate it if you could follow this guidance to provide feedback. Thank you for your time.

Answer 2

To compile a keyboard layout using Visual Studio, ensure that you have set up your project correctly. Here are some steps and considerations that may help you produce a functional DLL:

Project Configuration: Make sure your project is configured to use the Windows Driver Kit (WDK). You should include the necessary headers and libraries that are part of the WDK in your project settings.
Include Files: Ensure that your project includes all required header files, such as kbd.h and winuser.h. These files are essential for keyboard driver development.
Precompiled Headers: If you are experiencing issues with precompiled headers, try disabling them in your project settings. This can sometimes resolve compilation issues.
Makefile and Sources: If you are using makefile and makefile.inc, ensure that they are correctly referenced in your project. Visual Studio may not automatically handle these files as it would in a command-line build environment.
Build Configuration: Check your build configuration (Debug/Release) and ensure that it matches the environment you are targeting (x64). Sometimes, mismatched configurations can lead to unexpected results.
Output Size: The difference in DLL size might indicate that the compilation settings or included libraries differ between the command-line build and Visual Studio build. Compare the settings to identify discrepancies.
Testing the DLL: After building the DLL, test it thoroughly to ensure that it behaves as expected in your Windows environment. If it fails to load or operate correctly, check the output logs for any errors or warnings that could provide insight into the issue.

If you continue to face challenges, consider consulting the WDK documentation for specific guidelines on building keyboard layouts and troubleshooting common issues.

References:

Share via

Compile a keyboard layout with Visual Studio

1 additional answer

Your answer