Which version of HLK do i need so my ndis LWF driver can successfully install in windows 7 to 11?

Hi,

The entire docs for HLK/HCK is really vague in my opinion.

I am still confused and not sure which version of HLK do i actually need to download in order for my driver to load in windows 7+?

In the following link:

https://docs.microsoft.com/en-us/windows-hardware/test/hlk/

There are more than 10 HLK versions, and to add to the confusion, I am not sure whether i need to have 10 test server for each of them and 10 client for each as well (so 20 machines/VMs total), or i need to install just 1 version for a test server and have 10 client machines (11 machines/VMs)? And do i need to somehow find the iso file for each of the build versions (for example windows 10 build xxx) that corresponds to a particular HLK version, and download and install that version of Windows for each of the clients?

Can someone explain to me what exactly i need to install and how many machines/VMs it is required for me in order for my NDIS LWF driver to get signed for windows 7+? Do i also need to install HCK, therefore racking up the total number of VMs i need to install to 30+? Isn’t this way too complicated or is it just me?

Will attestation signing do the trick here for installing my NDIS LWF for 7+, or i really need to pass these tests?

I’ll share my understanding of this, though I’m far from one of the experts here.

It would be lovely if there was a single test suite that would qualify a driver for a wide range of OS releases, but that doesn’t seem to be the way Microsoft has set this up. The HCK controller can be used for pre-10 operating systems, and different HLK controllers are used for each unique Windows 10 or 11 version. I have two dedicated physical machines I use to perform kernel driver testing: a controller system and a target system.

The controller system dual boots into either Server 2012 for hosting the HCK controller, and Windows 10 Pro for hosting VMWare Player that in turn runs Server 2016 VMs, one for each of 8 Windows 10 or 11 versions I test against.

The target system is madly partitioned to boot into each of the supported targets from Windows 8.1 to Windows 11. The ISOs for the various operating systems are available from https://my.visualstudio.com/downloads , assuming you have the necessary Microsoft subscription. I use a tool called Rufus to create a bootable install image onto a USB drive when I need to set up a new target OS. (One caution about setting up targets for Windows Server editions: Microsoft’s prerequisites currently say “If you are testing against a Windows Server, you install a DataCenter edition and the ‘Full Server’ or ‘Server with a GUI’ during Setup,” but if you follow that advice your tests will fail the “Operate in Server Core Test.” Install the DataCenter edition, but choose the non-GUI option. It’s no fun to get everything set up from the command line, though.)

The controller and target machines are cabled directly to one another with a short CAT6 cable and have static IP addresses, so they’re well isolated.

I’ve performed some attestation signing on a coworker’s behalf for some drivers, and that is a wonderfully simple process. The main drawback, as far as I can tell from the documentation, is that attestation signing can only be used for drivers meant for Windows 10 or later, which may be fine for some customer bases.

I’m holding out a miniscule hope that an expert chimes in and tells us both that it’s all much, much simpler, but this is my current understanding of what is needed to secure Microsoft’s signature on a kernel driver.

(See also this thread from a few years ago where it’s suggested that testing for all Windows 10 versions is probably not strictly required. You may have some leeway to decide how thorough you want to be about it.)

…different HLK controllers are used for each unique Windows 10 or 11 version.

Although there ARE myriad such versions, if you test your driver with the oldest WIn 10 version you need to support, that signature works for ALL Win 10 and WIn 11 systems.

1 Like

@Tim_Roberts said:
Although there ARE myriad such versions, if you test your driver with the oldest WIn 10 version you need to support, that signature works for ALL Win 10 and WIn 11 systems.

I’d be glad to take this route, but I’m uncertain of whether that is a truly good practice or an expedience that we can simply get away with.

If there are any issues with earlier OS versions, I’d much rather find them in some extra hours of testing than have customers encounter issues; on the other hand, in my limited experience, it is rare to have an issue show up on one Windows 10 version but not another — unless there’s an issue with latest HLK, playlists, or the filters themselves.

Is HLK testing across all supported builds considered a best practice, an unnecessary expenditure of resources, or something in between?

The standard practice is to test with one HLK and one HCK. The cost of testing with all HLKs is absurd and there really is no benefit. I generally used the latest released HLK and, as has been mentioned here repeatedly, check all available boxes for compatibility. Using the earliest W10 version you need to support , as Tim suggested, is fine too.

These tests suites are generally not going to find many real world bugs in your code, you have to do your own testing as well, and that effort would be a much better investment.

1 Like

The HLKs don’t replace your own regression tests or your own QA. The overall value of the HLKs as QUALITY tests is highly dependent on the driver type you’re testing, and whether the features that your driver implements match what the HLKs test. I know that’s kind of an obvious statement, but it’s really key to think about. In evaluating the HLKs as “quality” tests, you need to have your own mental playlist. There may be tests that you don’t care about – or that you could NEVER pass because of the way your driver/device is designed to work.

Remember: The #1 job of the HLKs is to test to ensure that your device and driver work well with Windows and provides users with the “experience that they expect” when using a standard peripheral with Windows. If that’s what “success” looks like for your device/driver (like, you know, you’re providing some consumer device) then the HLKs can be a pretty decent match. But the more specialized your device/driver, and the more unique its expected environment, then the less value the HLKs provide.

For example: Does having the system sleep and wake about a zillion times, while there’s I/O in progress to your driver, provide a good match with what you need or even want your driver to do? If my device is designed to work in a consumer laptop, then probably the answer is yes. If my device is designed to manage the command, control, and communications for an aerial surveillance drone, then… probably not (the first time the system goes to sleep, that drone is going to go into some sort of "emergency mode to prevent it from randomly falling out of the sky).

Likewise, the tests for file system filters: A lot of these tests are terrific, assuming your file system filter is designed to be 100% transparent to the rest of the system. Antivirus? Yes, that’d be a good fit. Encryption, compression, or something else that changes the “shape” of the underlying data? Then, not a good fit at all.

You need to use your judgement. And running multiple versions of the tests adds nothing for ME more than time, annoyance, and confusion.

HTH,

Peter

1 Like

Thanks @“Peter_Viscarola_(OSR)”, @Mark_Roddy, and @Tim_Roberts — you’ve made my life so much better with your answers.

In particular, I don’t believe I will ever bother trying to create a Driver Verification Log again to pass Windows Server testing. Not that I won’t still make use of the static analysis and SDV tools, but I’ve found that the DVL creation bug I posted about four years ago still exists in VS2019 16.11.12 with the Windows 11 WDK. I’ve just killed an afternoon trying to coax a DVL out of one particular driver project.