The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.
Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/
This is a solution to the question raised in this post, on the off chance others run into the same issue and could find only the previous post, without any concrete solution.
The error message "A mismatch between the PNP/INF version and the KMD file version on the graphics adapter has been detected. The adapter will fail to start." is reported by the DXGI runtime when trying to load a graphics driver whose version numbers do not match expected values (as demonstrated on MSDN). The confusing part is that nowhere does it make it clear how you are to go about setting those version numbers. Thus, this post, which hopefully makes it clear for anyone else searching for this solution how to proceed.
By default, the version number assigned to the INF
DriverVer tag comes from the date and time when the project was built. This explains why the error message would appear intermittently - if you built the project at the correct time, it would just so happen to have a "valid" version number! A correct value for this tag can be hard-coded by modifying the "Driver Version Number" of the Stampinf settings of the project properties in Visual Studio.
For a UMD DLL, the "file version" must match the INF version specified above. This is accomplished by adding a version resource to the project (Add -> Resource... -> Version), with the
FILEVERSION set to the same version number as the INF.
A KMD sys file also needs to have a resource file added, but (at least in the version of VS I'm using) just trying to add one like was done with the UMD DLL assumes that usermode header includes will be available, which they will not be, and it will not compile the resource file properly. Fortunately, this very website has a nice blog post describing exactly how to get around this issue. Set the
FILEVERSION tag exactly as for the UMD DLL.
Once I set everything properly, I'm no longer seeing that error when the driver loads.
I do hope this helps someone not spend hours digging into this issue as it randomly pops up due to the build-time-based nature of the default version values!
|Upcoming OSR Seminars|
|OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!|
|Kernel Debugging||16-20 October 2023||Live, Online|
|Developing Minifilters||13-17 November 2023||Live, Online|
|Internals & Software Drivers||4-8 Dec 2023||Live, Online|
|Writing WDF Drivers||10-14 July 2023||Live, Online|