I've noticed that 24H2 enforces the drivers to be installed properly, rather than doing your own magic. Creating and properly installing the driver package using the inf file seems to be no issue.
However, when I want to somehow specify the program files using dirid 24 as an example, I'm getting 0x00000002.
Image Path = \SystemRoot\Program Files (x86)....\xyz.sys
inf: Group = FSFilter Security Enhancer
inf: Dependencies = FltMgr
!!! inf: Failed to query service configuration. Error = 0x00000002
As I assume SystemRoot is the Windows folder it self. Is there no way other than manually editing the servicebinary path to properly point to program files? I'd like to keep my drives at the application folder.
Is this still possible? (The test is happenning on Windows 10, but I am just trying to point out whether if it was ever allowed to be referenced for kernel installation)
%SystemRoot% is the Windows folder. You are not allowed to place files in \Program Files. Just that simple. Driver binaries belong in \windows\system32\drivers, where they can be protected.
Thanks, wanted to confirm this theory as the documentation was NOT specific about this. Especially many drivers out there used the program files folders throughout the years with no issues.
It still doesn't explain to me (i copy the drivers via my installer to program files) how I cannot assign the service path to program files. If you manually edit the registry and adding the driver there, without installing it as a package, it works fine, windows loads it without hassles as well.
Mostly because I think I could easily bypass this if one of the dirids would point to the root drive letter
If you want to manually create a service entry you can set things to anything acceptable by SCM. Using an INF means that PNP is going to assert some level of control over what you're doing.
It's not a technical issue, it's a philosophical issue. Microsoft does not want you to do that. They've long said it was a bad idea, and now they are enforcing it. When drivers all follow the very narrow rules, things like automated upgrades become much easier. The approach you happen to like is totally irrelevant to the billions of machines they have to support.
Mostly because I think I could easily bypass this if one of the dirids would point to the root drive letter
No, because that would also be deprecated. A PnP driver must be in %SystemRoot%\System32\Drivers. End of story. As Zac says, a non-PnP driver can do whatever it want, but it doesn't need an INF.
Makes sense, but lately since 24H2 they also enforce you to become a "PNP" driver, even if you are just a simple mini-filter no?
Atleast my experience shows that when I was configuring my driver manually through the registry, it all works well, except that 24H2 removed the driver from the registry during the update. Putting it back is no hassle, but as you said, its deprecated.
Do I understand this correctly? Appreciate your answers and Zac's!
One thing which comes to mind is that Microsoft's INFVerif should be flagging these issues too. This is one of the steps which happen when submitting drivers to Microsoft for signing, and was when we learned we could no longer keep the drivers in the Program Files folder.
Historically people have been using an INF file like a script using [DefaultInstall] (passing it to setupapi!InstallHInfSection) to install their class/disk filters. This was fine but it causes a lot of weirdness on upgrade: setup/PnP can't always recreate the result of that script execution, so you might come out the other side of an upgrade with a bunch of important stuff missing.
We ended up settling on the idea that PnP would ingest these INFs into the driver store, so we could then re-run them any time it was necessary and make sure we're in a good state. This added some constraints to what you can do, but imo they're minor.
AlanAdams is correct, InfVerif /h should catch any of these issues and help you out.
In that case, that mostly works for different driver types like Universal, or Windows Driver. "Desktop" being legacy does not work.
This also reminded me that now i can switch back my driver to universal, since program files is no longer the case for me.