The last time I did a build of my driver project and had to run it through the HLK was back in June of 2025, and the necessary HLK versions that were used on a farm of VMs collectively allowed for generating HLKX package files for the following builds of Windows:
Windows 10 22H2 x64
Windows 11 23H2 x64
Windows 11 24H2 x64 & ARM64
Windows Server 2016 1803 x64
Windows Server 2019 1809 x64
Windows Server 2022 21H2 x64
Windows Server 2025 24H2 x64
Now, with a new build of the driver ready for HLK testing, the same previous set of VMs is being used plus the following additional ones:
Windows 11 25H2 x64 & ARM64
Windows 11 26H1 ARM64
With the latest HLK for Windows 11 24H2/25H2 & Windows Server 2025 24H2, along with the HLK for Windows 11 26H1, I’m finding that the '“Static Tools Logo Test” is now required based on the playlists that were loaded, and the test is failing. It was odd that the HLK & playlist for Windows 11 26H1 (ARM64) did not include the “Static Tools Logo Test”, but the HLK for Windows 11 25H2 (Updated February 2026) does require it and that’s where the test is being executed and is failing for both x64 & ARM64.
Where I’m lost is getting CodeQL into my build process, which occurs on an Azure-hosted agent where the build pipeline is using the VM image “windows-2025-vs2026”, with Visual Studio 2026 and EWDK v10.0.28000.1839; after the driver project is built, the ‘.sys’ & ‘.cat’ files are signed and packaged together with the ‘.inf’ file into a ‘.zip’ archive which then gets deployed on the HLK client VMs. On my local dev system, I use Visual Studio 2026 with both the Windows SDK & WDK installed at version 10.0.28000.1839 for making builds of the driver for local testing in a VM, but those builds are not suitable for HLK testing since they can’t be signed with our EVCS.
It’s not clear if just one version of CodeQL is to be used and the resulting output provide to all of my HLK controllers or if multiple versions of CodeQL need to be used to independently produce output targeting different HLK versions.
Is there reasonably good tutorial for CodeQL which covers end-to-end setup to ensure correct usage to meet the HLK testing requirements?
From my attempts at following Microsoft’s instructions at Run CodeQL Analysis for Windows Driver Certification - Windows drivers | Microsoft Learn , I have done the following:
- Downloaded & unzipped the 64-bit Windows version of CodeQL v2.24.1 as it’s recommended for HLK for Windows 11 26H1.
- Used the CodeQL “pack download” command to install the Windows Driver v1.8.2 & C++ Queries v0.0.4 packages.
- Opened a developer command prompt from Visual Studio 2026 with the solution opened which contains my driver project and created a CodeQL database.
What I’m mostly stuck on are the following:
I build Release & Debug configurations for both x64 & ARM64, and eventually, after HLK testing is done, I submit 4 separate HLKX packages for signing by Microsoft. The rational behind getting debug builds signed is that in the case where a customer experiences a bugcheck caused by the driver and the optimized release build doesn’t yield enough information to isolate the root cause, there is the possibility of installing a debug build of the driver to improve the troubleshooting process.
-
Do I need to prepare 4 separate CodeQL databases to match the builds of the driver which will be undergoing HLK testing?
- The same question applies then to processing the database and eventually producing a single DVL file or multiple DVL files to deploy to the HLK client computers where different builds of the driver are being used for HLK testing.
-
Does it make any difference if the CodeQL database is built locally on my dev system using the same source code as the actual ‘.sys’ file is built in an Azure-hosted build pipeline? I’m not clear on the relationship between the provenance of the CodeQL database and resulting DVL files vs. the provenance of the actual ‘.sys’ binary when it come to running the HLK “Static Tools Logo Test”.
-
Does it make any difference if the CodeQL database is created using a build command where the file & product version resource information differs from the ‘.sys’ file that is built in the pipeline?
-
Is CodeQL actually building my driver project, or is it just examining the msbuild.exe command line and then utilizing MS build in some manner to emulate a build such that it allows all source code being built to be identified for analysis purposes? I ask because there are NuGet package dependencies which are used to pull in a reusable C++ code library to provide kernel-mode utility classes, etc., and it’s not clear if CodeQL will require that external source code for analysis purposes.
-
Is only the output from CodeQL (converted to DVL format) required, or is the Driver Static Verifier within Visual Studio 2026 w/the WDK extension installed still relevant?