Is Running the HLK Tests REALLY a Best Practice?

I can hear you now, scoffing as you read the latest issue of The NT Insider:  “You OSR people actually think running the HLK tests is a Best Practice?   Seriously?”  I know this is what you’re thinking, because we had this same “discussion” internally among members of the OSR engineering staff.

It turns out that how useful the HLKs are depends almost entirely on the type of driver you’re writing.

If you’re writing a driver for a piece of custom hardware, and you’re testing in the Unclassified category, running the HLK tests is likely to add little value over your own basic functional testing.  Sure, you can run the Device Fundamentals (DevFund) tests.  And, those tests will test basic stuff like whether your driver can be put into low-power states and awaken successfully. But we suspect that you don’t need the HLKs to sort out such fundamental things.  Or maybe you do.  In any case, it won’t hurt you any to run the HLKs.  And maybe, just maybe, the tests might uncover a bug.  I suspect this would be especially true if you’re one of the less experienced Windows driver devs.

Where the HLK tests really shine (gad!  I can’t believe I actually typed that in a sentence) are in the specific device categories.  For example, we’ve found that running the HLK tests for File System Filter drivers is extremely valuable.  We’ve also found things like the SCSI Compliance tests for StorPort drivers to be very useful.  The HLK tests are at their best when they attempt to determine if the system behaves differently with your driver present than without it. It’s certainly better to get a feel for this periodically than to stay blissfully unaware and get a rude awakening in the future when a customer’s system fails with your driver installed.

So, yes.  Running the HLK tests on your driver really is a Best Practice.