Driver Signing - Manual Review for x64 build while ARM64 build gets signed immediately

NTFSD
1

I have a file system mini-filter driver which gets built for both x64 & ARM64 and is then run through HLK testing in a VM lab where "HLKSetup - 24H2 (Updated July 2025)" is installed on one VM as the controller and on 3 VMs configured as test clients. There are x64 builds of Windows 11 24H2 & Windows Server 2025 24H2 along with an ARM64 build of Windows 11 24H2.

I'm using the required playlists "HLK Version 24H2 CompatPlaylist x64 ARM64.xml" and "HLK Version 24H2 CompatPlaylist x64 ARM64 SERVER.xml" that were available when the July 2025 update to the HLK was released. Ditto for the updated "UpdateFilters.sql" file taken from the "HCKFilterUpdates.cab" and applied to my controller.

For whatever reason, for ARM64, there are only 2 tests: "Mailslot Basic" and "Registry Callback Tests", while for x64 there are 18 desktop tests and 20 server tests. For x64, both desktop & server have the "Installable File System Filter Test". For Windows Server 2025 24H2, this test always has failures as follows:

In the log "Ifstest-Local-NtfsResults.wtl":

170C.1E10 : +TEST+SEV2 : Test :FlushBuffersRootTest
Group :SectionsCaching
Status :C000004E (IFSTEST_TEST_STATISTICS_ERROR)
Description :{Msg# seccache!flushrot!18} The first write statistic
was 25616384. The second 25616384. The total number
of bytes modified on the files is 291088. It does
not appear that all data was flushed.
WDKTUID: A72C4D26-977B-19CB-2E11-D6F93917D718

ifstest.exe g: -g Virus -g Encryption /n Ifstest-Local-NtfsResults.log /N 356789AB /T /p /m /E /j /r c: -d \Ntfs -a \datacoh.exe /u ifstest /U *rw53w52

In the log "Ifstest-Local-CntfsResults.wtl":

DB8.F60 : +TEST+SEV2 : Test :FlushBuffersRootTest
Group :SectionsCaching
Status :C000004E (IFSTEST_TEST_STATISTICS_ERROR)
Description :{Msg# seccache!flushrot!18} The first write statistic
was 9536512. The second 9536512. The total number of
bytes modified on the files is 291088. It does not
appear that all data was flushed.
WDKTUID: A72C4D26-977B-19CB-2E11-D6F93917D718

ifstest.exe i: -g Virus -g Encryption /n Ifstest-Local-CntfsResults.log /N 356789AB /T /p /m /E /j /r c: -d \Ntfs -a \datacoh.exe /u ifstest /U *rw53w52

In the log "Ifstest-Local-RefsResults.wtl":

1084.19D4 : +TEST+SEV2 : Test :FlushBuffersRootTest
Group :SectionsCaching
Status :C000004E (IFSTEST_TEST_STATISTICS_ERROR)
Description :{Msg# seccache!flushrot!18} The first write statistic
was 831488. The second 831488. The total number of
bytes modified on the files is 291088. It does not
appear that all data was flushed.
WDKTUID: A72C4D26-977B-19CB-2E11-D6F93917D718

ifstest.exe o: -g OpenCreateGeneral -t EnumReparsePointsTest -t ChangeNotificationReparseTest -t EaInformationTest -t CompressionInformationTest -t LinkInformationTest -t AlternateNameInformationTest -t StreamInformationTest -t StreamStandardInformationTest -t HardLinkInformationTest -g EaInformation -t SetCompressionTest -t AVChangeLogTest -g ObjectId -g MountPoints -g SparseFiles -g Encryption -g Quotas -g StreamEnhancements -g DefragEnhancements -g Virus /n Ifstest-Local-RefsResults.log /N 356789AB /T /p /m /E /j /r c: -d \RefsDisk -a \datacoh.exe /u ifstest /U *rw53w52

The same tests are successful on FAT16, FAT32, EXFAT and UDF volumes on Windows Server 2025 24H2.

Since the HLK test results are 100% clean for the ARM64 build of the driver, the driver submission gets uploaded, automatically analyzed, signed & finalized within perhaps 10 to 15 minutes.

However, with the x64 build having these failures which haven't been mitigated by application of a filter, the x64 driver submission always goes into a "Manual review" where the following is displayed: "We detected some issues while validating your package and are manually reviewing the package for additional filters." When this occurs, the driver submission does eventually get processed to where Microsoft has signed & finalized it, but ends up taking 3 to 4 days.

Questions:

  1. Is there any possibility that there is something "wrong" with the NTFS, CNTFS and REFS volumes on Windows Server 2025 24H2 that would result in this failure occurring?

  2. Is there an additional filter available which would mitigate this failure and result in a "clean" HLK package that would get rapidly signed & finalized?

  3. Is there somebody at Microsoft that supports the HLK who can be contacted to determine if this is a known issue that will get resolved with an updated HLK or updated filters in the near future?

2

I just ran the HLKs again today and I don't have these failures on Server 2025. I'm using the VHLK (July update).

Have you confirmed that the errors happen even without your filter?

3

Not yet, no, but I can set up that testing scenario and report back on the results.

Just to confirm, after loading the project, I should do the following to perform this testing scenario:

  1. Click on "Selection".
  2. Do not uncheck the box for the driver. Instead, unload the driver and disable it. If the box is unchecked then the no tests can be performed.
  3. Click on "Tests".
  4. Check the box for "Installable File System Filter Test".
  5. Click on "Run Selected".
  6. Wait for the test to complete and review the results.

Note, although this driver is built and loaded as a file system mini-filter driver, it's primary functionality is of the "callback" type for process / thread / load image events as well as some registry filtering. It doesn't actually bind to any volumes or intercept any file system operations. I had the expectation that as far as this particular test goes, the driver shouldn't be a factor at all.

4

Under Selection you can just pick an inbox minifilter driver instead of your driver and then do the test. I'd do this on a clean system that's never had your stuff on it just for my own sanity...

And for completeness I used HyperV VMs as targets. For the test drives I just have a single VHD with all the volumes on it and I attach it to the VM from the host.

5

Thanks and noted. I'll provision a new VM running Windows Server 2025 24H2 and put the HLK client on it. I've got the required testing drives as .VHDX files with original copies saved so that I can add them to a new VM and bring them online in the disk manager mmc snap-in and then get the correct drive letters associated with them.

6

I'm still getting a new VM provisioned, but I went back and re-ran the "Installable File System Filter" test on the existing VM, but with "WOF.SYS DEVICE\HARDDISKVOLUME3" selected and my driver unloaded & disabled. The test still fails in the same way with the symptoms. When I've got the new VM provisioned, I'll re-run the test and see if a fresh environment makes a difference.