In contrast to what Microsoft suggests (https://msdn.microsoft.com/en-us/library/windows/hardware/ff544309(v=vs.85).aspx?f=255&MSPPError=-2147217396), Windows 10 Technical Preview does not support KMDF version 1.15.
Using VS 2015 CTP with WDK 10 while following the official instructions (https://msdn.microsoft.com/en-us/library/windows/hardware/hh439665(v=vs.85).aspx) would result in a faulting driver: STATUS_FAILED_DRIVER_ENTRY (0xC0000365, 3221226341) and DriverEntry not being called (because WdfVersionBind fail).
Changing KMDF version to 1.13 would fix it.
Tested on x86 build 9926.
FYI,
Yoav Orot.
Hi Yoav,
Could you please tell us the WDK version you’re using? You can get that from Visual Studio menu Help > About, it will be at the end of the installed products list, something like “Windows Driver Kit 10.0.10041.0”.
You can also get more information about this failure by enabling Loader Diagnostic message with WDFVerifier, see here: https://msdn.microsoft.com/en-us/library/windows/hardware/ff548422(v=vs.85).aspx
I would also recommend installing the 10041 tech preview build and using the latest WDK available. Having all components in-sync is necessary to avoid issues endemic to preview tech that can change from version to version.
Let us know how it goes.
Yoav… Just FYI: It works for me.
Peter
OSR
@OSRDrivers
To elaborate, we’ve re-enabled the function count check for recent builds now that we’re nearing release. That means drivers compiled with an old version of the kit (pre-WinHec) will have a mismatched function count, and will no longer load. Recompiling with a newer kit will fix your issues.
If you’re curious, we’ve released our framework code as open source, and you can see exactly what’s happening. Check out FxLibraryCommonRegisterClient: https://github.com/Microsoft/Windows-Driver-Frameworks/blob/master/src/framework/kmdf/src/librarycommon/fxlibrarycommon.cpp#L325. You can see our disabled check (and the associated KdPrint), and with our next source iteration you’ll see the ASSERT enabled.
Also remember to unmask your KdPrints!
Alex, Peter and David,
Thank you for responding.
Alex:
> Could you please tell us the WDK version you’re using? You can get that from
> Visual Studio menu Help > About, it will be at the end of the installed products
> list, something like “Windows Driver Kit 10.0.10041.0”.
My WDK version is 10.0.10041.0.
> I would also recommend installing the 10041 tech preview build and using the
> latest WDK available. Having all components in-sync is necessary to avoid issues
> endemic to preview tech that can change from version to version.
After updating to version 10041, I was indeed able to install my driver, configured as 1.15.
I’ve also tested 10061 (fast ring), however, I couldn’t connect WinDbg - “KDNET protocol version unsupported. You may need to upgrade your debugger.”.
I’m using WinDbg version 10.0.10041.3 X86 from the above WDK.
David:
> To elaborate, we’ve re-enabled the function count check for recent builds now
> that we’re nearing release. That means drivers compiled with an old version of
> the kit (pre-WinHec) will have a mismatched function count, and will no longer
> load. Recompiling with a newer kit will fix your issues.
It seems that the problem is not related to your recent re-enabling (fxlibrarycommon.cpp#L325), but to the fact that the maximum count of WDFFUNCTIONS of the older Wdf01000 (9926) is less by one from the count of the client 1.15 (WDK 10.0.10041.0).
In other words, using WDK 10.0.10041.0 with build 9926 would make the driver fail if its version is 1.15 (see fxlibrarycommon.cpp#L279).
I set KDMF DbgPrintOn and got “Wdf01000: LibraryRegisterClient: version mismatch detected in function table count: clienthas 0x1bc, library has 0x1bb”.
> If you’re curious, we’ve released our framework code as open source, and you can
> see exactly what’s happening. Check out FxLibraryCommonRegisterClient:
> https://github.com/Microsoft/Windows-Driver-Frameworks/blob/master/src/framework/
> kmdf/src/librarycommon/fxlibrarycommon.cpp#L325.
That’s a welcome move!
Regards,
Yoav Orot.