I can mention that SeDeleteClientSecurity() has also changed from macro to an export so I had the same problem with that.
Thank you all for the comments. I believe that I now have this solved - or at least qualified to the point of understanding what I need for a working driver package on latest Windows 10.
It appears that VS 2022 insists on using latest WDK v10.0.26100.1 (is this WDK Windows 11, version 21H2??). Although drivers built using that WDK will load properly on Windows 11 23H2, they will not load properly on Windows 10 22H2.
To get that driver package to load on Windows 10:
- ALL instances of WDK were uninstalled on host system
- WDK Windows 10, version 2004 (v10.0.19030.1000) was installed
- driver projects were built using VS 2019; KMDF version was set to 1.31.
This resulted in a driver package that was able to load under both Windows 10 and Windows 11.
So in summary:
"Later" WDKs are no longer compatible with "earlier" OS.
That is, it appears that if one wants to build a WDF driver package that will load on recent Windows 10 (and later), one needs to still use Visual Studio 2019, along with a WDK released specifically for that OS, e.g. Windows 10, version 2004.
If anyone feels that this is not a correct assessment of the issue, or that additional information should be added, please feel free to comment with any feedback.
Thank you again for all of your support here.
As a best practice I would recommend using the EWDK for your builds as it avoids the mess of modifying visual studio build environments.
The new nuget based WDK also does this, and is developer friendly and you can directly record the nuget WDK versions in your git branches, so that is now also a good alternative.
Thank you for that suggestion, Mark.
But if I understand the documentation from the MS Learn docs, if I download the latest EWDK, wouldn't I still be building with VS 2022 and the WDK 10.0.26100.1?? If so, wouldn't that still produce a driver package that will not be able to load on Windows 10?
I suppose I could download a previous version of the EWDK - for example, EWDK for Windows 10, version 2004. Then I should have the complete environment to build a working driver package for Windows 10 22H2.
Perhaps that is worth a shot...
@Mark_Holiday Are you targeting the oldest version of Windows that you need to support in your driver properties?
We routinely build drivers using the latest WDK and run them on down-level versions of Windows. Though I admit to not testing the very latest Win11 WDK for down-level capability.
@Peter_Viscarola_OSR I think now that therein lies the issue that began all of this.
If I simply load the exact same solution and set of project files that we now have working with VS2019 and WDK Windows 10, version 2004 into the VS2022 IDE and begin the build, it complains with the error:
1>C:\Program Files (x86)\Windows Kits\10\build\WindowsDriver.common.targets(299,5): error MSB4062:
The "ValidateNTTargetVersion" task could not be loaded from the assembly
C:\Program Files (x86)\Windows Kits\10\build\bin\Microsoft.DriverKit.Build.Tasks.17.0.dll.
Could not load file or assembly 'file:///C:\Program Files (x86)\Windows Kits\10\build\bin\Microsoft.DriverKit.Build.Tasks.17.0.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
This is because the version of that file in that location is Microsoft.DriverKit.Build.Tasks.16.0.dll
(If I am not mistaken, 16 is the toolset version for VS2019, and 17 is for VS2022.)
If I put "Windows 10.0.19041" as the _NT_TARGET_VERSION in the Driver Settings Property page, I receive the same error.
So it seems that VS2022 is insisting on a later WDK toolset for driver projects.
(Can we confirm this?)
And then the subsequent load issue ensues because a driver entry point is not found... etc., etc.,...
Hmmm... that's not where I was suggesting you change it.
How about here:
(ignore the whole "Universal" thing... this particular driver just happens to have that set, cuz I haven't changed it).
1 Like
Is what I mentioned not the same as what you are showing?
How does that hex value that your have map to the version string that I used?
Sorry... I was referring to the Target OS Version selection, specifically.
The hex value for _NT_TARGET_VERSION that I'm using above refers to Win10 Redstone 1 (which is the oldest target OS version that our driver supports).
We're building this driver using the latest WDK and VS 2022, and it definitely load and runs on Win10 and Win11.
I am really and truly mystified by the issue you're having. A long-standing tenet of Windows driver development is downward and upward compatibility. If this has been broken, that'll be very bad news for the whole industry... if you've found yourself caught in an edge case, I'd really like to know (as, I'm sure, would the WDK team). Which is why I'm following your issue so closely.
I wish I could provide you with more help to root-cause this.
Thank you for that, @Peter_Viscarola_OSR.
If my entry for Target OS Version is "Windows 10" or "Windows 10 or higher", I receive the same error described above:
The "ValidateNTTargetVersion" task could not be loaded from the assembly...
One task that I attempted during this whole investigation was to simply build and attempt to install the netvmini sample driver using the latest WDK, targeting Windows 10 or higher, and that exhibited the same "driver entry point not found error" when loading that driver. I submitted an issue on the MS github site, that has since been labeled a "bug".
That illustrates as simply as possible the behavior that I have experienced: using the latest WDK, certain drivers will not load on Windows 10 22H2.
I am as surprised by this lack-of-backward-compatibility support issue as you are. I am not sure why there is not more clamoring in the driver community about this, and if there is something that I am indeed missing or misunderstanding, I would like to find that out.