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/
Just FYI, and in case anyone sees any good wisdom to share:
Sometime between December 2022 and now, the INF Verification involved in the Attestation signing process was updated to apply new requirements.
Specifically the one that seems to have bitten us is that when setting registry values, now it's not allowed to reference INF directory IDs using the strings syntax. e.g. "%11%\system.dll"
The error message from INF Verification helpfully suggests that one should use "%%SystemRoot%%" or "%%ProgramFiles%%" instead of the directory IDs. Note the implication here is that the registry value now MUST be REG_EXPAND_SZ, and the substitution with the actual path now happens at runtime when the registry value is read instead of during the .INF processing.
Unfortunately "does the consumer of this registry value actually support REG_EXPAND_SZ?" is a limitation as well, since REG_EXPAND_SZ behavior is not transparently applied by the registry APIs. We were lucky that all the registry values, save one, did already support REG_EXPAND_SZ.
But it appears that Microsoft NetSetupShim.dll's reading of the "ComponentDll" value does not support REG_EXPAND_SZ, at least on Windows 11, Windows 10 and Windows 7 platforms.
This was one of many DLLs we had intentionally moved into a product-specific folder name space, seemingly in line with Microsoft's intentions that we not all install and contend over the SYSTEM32 folder namespace. Our "successfully installing until now" ComponentDll syntax in out NetClient-class INF had been referencing a DLL in our Program Files folder:
But adding the 0x20000 flag to write the value as REG_EXPAND_SZ causes attempts to install from the .INF fail with a form of "invalid data type" or "data type mismatch". Exactly which error code will be returned varies depending upon which Windows platform you are on. The call stack as identified by Process Monitor says it's NetSetupShim.dll reading this value, successfully, but then apparently internally decides the value must be REG_SZ type to succeed.
So we're in the process of changing the INF to install this DLL into the SYSTEM32 folder instead, so that no explicit path will need to be specified. Given that now neither "%11%" nor "%%ProgramFiles%%" will be supported for this "ComponentDll" value.
|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||13-17 May 2024||Live, Online|
|Developing Minifilters||1-5 Apr 2024||Live, Online|
|Internals & Software Drivers||11-15 Mar 2024||Live, Online|
|Writing WDF Drivers||26 Feb - 1 Mar 2024||Live, Online|