I am testing my minifilter driver in the Windows Hardware Lab Kit environment.
I followed the setup steps described in the official Microsoft documentation. ( Windows HLK Getting Started | Microsoft Learn )
When I test my unsigned minifilter driver:
- Test signing is enabled on the client machine.
- The minifilter is loaded manually.
- It is selected from the WHLK software device list.
- I load the playlist “HLK Version 25H2 CompatPlaylist x64 ARM64.xml”.
The playlist lists two tests:
- TDI filters and LSPs are not allowed
- HyperVisor Code Integrity Readiness Test
The second test fails with the following message:
… Driver Verifier settings validation failed. Driver guard.sys did not load.
I suspect this is because my minifilter driver is unsigned.
I have read documentation and community discussions on this topic, but I am still not completely sure.
Do I need at least an attestation signature to test my minifilter driver in WHLK, or can I run these tests with test signing enabled?
Thanks for any advice or experience you can share.
I’ve successfully run test signed file system filters under the HLK (on x64 and ARM64) so that’s not the problem.
Have you tried to run the tests on an inbox minifilter to validate your configuration is correct? That’s always the first thing I do because if it doesn’t work for them it’s not going to work for me…
1 Like
Out of curiosity, is there a recommended inbox mini-filter driver that is considered to be a “gold standard” for performing that kind of a sanity check? I see this mentioned as a means of verifying that the HLK environment is set up correctly, but I don’t ever see a specific inbox driver mentioned as being the standard guinea pig.
No, there’s no standard one to pick. I have to assume that all inbox drivers are required to pass the HLK tests, so in theory any of them should be fine..
That being said, picking a mini-filter that’s in your altitude range is a good idea if possible (e.g. I’d pick Defender if I was going to write an A/V filter). If there’s nothing inbox that’s similar to what you’re building then just pick one.
(And for completeness: note that this applies to other driver types as well. For example, we recently wrote an NVMe storage adapter driver and wanted to run the HLK tests on it. The baseline for that was using the inbox NVMe adapter driver to see what tests ran and what did/did not pass. If we had been writing a NIC driver we would have picked an inbox NIC as the baseline, etc…)