I was trying to copy my KMDF solution, created with VS 2022 from one PC to another. On that destination machine, I installed a fresh copy of VS 2022, then also followed all the steps to install the latest SDK and WDK from here.
But then when I tried to build my KMDF project on a destination PC, I got an error that it cannot include ntddk.h.
OK, so I decided to create an empty KMDF project in VS 2022 on the destination PC. It created it OK, but then when I tried to build that sample KMDF solution it also gave me:
driver.h(17,10): error C1083: Cannot open include file 'ntddk.h': No such file or directory
Any chance you failed to install the WDK extension in Visual Studio? They've changed things up in the last year, and I'm dealing with a similar problem at the moment. This all worked fine a year ago, at least for me. I have the additional requirement of using an older WDK, that used to work fine with VS2022.
" Starting with version 17.11.0, the WDK VSIX is included as an individual component in Visual Studio. Before installing the WDK, the installer checks if a compatible version of the VSIX is already installed. If the WDK VSIX is not found, users will be prompted to install it. To install the WDK VSIX, launch the Visual Studio Installer, select Modify, navigate to the Individual Components tab, add Windows Driver Kit, and then select Modify again."
Yep @Alnoor_Allidina you're right, the VSIX is the issue. When I check properties pages for this KMDF project it's missing pretty much everything that has to be there for a driver. The issue is that I can't seem to install that VSIX extension on that OS. The VS installer shows "Windows driver kit" as checked, but it doesn't seem to install it.
I'm not even sure where it places it now? To try to install it manually. It doesn't go into C:\Program Files (x86)\Windows Kits\10\vsix anymore. Any idea?
Thanks for confirming. I literally wasted 3 days already trying to build my KMDF driver (or even MSFT own sample driver project) after doing a fresh install of VS2022 + WDK on this other PC.
The issue is that the "Windows Driver Kit" feature in the VS installer, or VSIX extension for VS that is supposed to provide build and configuration environment for drivers does not seem to work properly. It is installed, I can create a new driver project in VS 2022, but somehow it disappears from the driver project itself. And to make matters worse they seemed to have moved or changed it from where it used to be.
So please update me if you find a solution. It is super frustrating.
The new Windows Driver Kit extension is an extension not an installed component. You install it, as documented, by using the Extensions menu item in VS2022.
Also, as long as you are modifying how you use these tools, you should consider using the nuget WDK/SDK components rather than installing them into VS.
I installed the WDK extension using the VS installer. The extension is successfully installed but there's still something missing. In previous new machine setups, I don't recall doing anything other than:
Install VS 2022
Install SDK
Install matching WDK
Install VS extension
Very strange. Thanks for the tip about nuget. I'll take a look.
can't help the fact that microsoft cannot keep their own terminology straight, but that thing you are installing from VS installer is the wrong thing.
For an up to date VS2022, (17.14.0 or later) the installer should only offer 'Windows Driver Kit' under SDKs, libraries, and frameworks, and not anything called 'Windows Driver Kit Extension'
Inside VS2022 itself the Extension Manager should display 'Windows Driver Kit' as an installed extension, and it should be version 10.0.26100.12 or later. If, as I strongly suspect, that does not appear under installed extensions, you need to install it using the Browse tab in the Extension Manager.
@Mark_Roddy I don't think MSFT allows to "just download it". Or at least I can't find it. It looks like they bundled it into the VS installer itself under "Windows Driver Kit". It even says that in the WDK page:
The problem is that once installed it doesn't always work. I tried it on several clean VMs and the steps that I explained above (and what @Alnoor_Allidina did as well) worked and everything was compiling fine.
But on this particular computer, that VSIX extension doesn't want to work. I can see it installed via the VS installer (it's checked there) but the project itself (in property pages) looks like it's just a user-mode C++ project. All driver specific stuff is not there. That is why it can't find ntddk.h and other files.
Moreover I can no longer get to that extension via C:\Program Files (x86)\Windows Kits\10\vsix like it used to be. And if I try to take it and install it manually from an older version from my working PC, I'm getting an error that the extension version doesn't match.
I did a little bit more digging today. And the only peculiar thing that I noticed on the PC that fails is that I can't seem to access the extensions store from VS 2022 -> Extensions -> Manage Extensions. When it comes up, I'm seeing this error:
A connection to the server could not be established because the following error(s) occurred: Response status code does nor indicate success: 429 ()
429 - is it "Too Many Requests"?
I wonder if that's the cause, in case that new version of that VSIX extension is trying to "phone home" and fails? @Alnoor_Allidina can you check on your end?
On my end, the vsix extension doesn't show that error.
As you pointed out, if I follow the same steps on a different machine (Server 2025 VM), everything works fine. My dev machine is freshly reset though, so I'm really not sure what has gone wrong.
Thanks. It's super frustrating not being able to use it. In my case I need to install it on that specific PC because of the attached hardware that I need for debugging. So I can't just use some VM for that.
Does anyone know where is that VSIX extension installed now? And if there's a log with error messages that it generates?
When I run into this it is because the Windows SDK selected in the project does not match the WDK version installed. I would double check which SDK is being used. If it is set to "latest installed" try explicitly selecting the SDK with the same version as the WDK you have installed.
You do not need to install VS on that specific PC in order to use it as either a debugging target or a debugging system. All you need is windbg and access to the source code and symbols.
Oh yeah, sure. Except that it is a lot more convenient to build a driver on the same PC that you're debugging it from - I mean the host. Obviously using WinDbg for debugging.
In that case I just move the .sys file to the target OS (via RDP), install/update it there, and then can start debugging right away. The WinDbg will load symbols and the source code automatically. Otherwise, without VS being on that same machine, copying .sys, .pdb, source files and then placing that .pdb in the correct GUID path for WinDbg to recognize it would be a pain (especially if you need to do it 50 times in a row during development/early debugging.)
But on my working VM, there was only one: C:\Program Files (x86)\Windows Kits
On the broken machine: I recalled that I had installed x64 debugging tools, WPT, etc. without using the SDK installer. So, I just kept uninstalling stuff until the C:\Program Files\Windows Kits directory disappeared.
At that point, I installed as follows:
VS 2022 17.13.7 with Windows Driver Kit enabled.
SDK 22621
WDK 22621
At the end of all that, my kernel compile is working again and the C:\Program Files\Windows Kits directory did not reappear.
Oh wow, thanks for posting this. It worked for me too!
I had that "x64 debuggers and tools" as well, but even after uninstalling it, it left some crap in the "C:\Program Files\Windows Kits" folder. So I had to delete it manually.
After that I installed VS 2022 community (from online), then ticked "C++ environment" and also in individual components, searched and ticked everything for "64 latest spectre" and also ticked "Windows driver kits". Then installed it all. After that also downloaded and installed WDK (from online). Started up VS 2022 and it worked! Now driver projects compile without any changes.
Wow. Idk, how to call it. A success, or the dumbest of bugs I've seen in a long run. It makes me think, how many people develop kernel drivers these days that this ludicrous bug hasn't been fixed for all this time. Just wow!
That sucked. 