Windows HLK DataImageCoherencyTest failure in Installable File System Filter Test -- 64-bit

Hi, all

I’m very new to Windows driver development and equally new to using the Windows HLK.

I’ve been tasked with SecureBoot code signing 32-bit and 64-bit versions of a Windows driver that a couple of our software engineers have developed. I’ve signed the drivers with our GlobalSign EV certificate and downloaded the latest version of Windows HLK I could find.

I’ve installed HLK Controller and Studio on a Windows Server 2019 machine, and I’ve set up two client machines, one running Windows 10 Pro for Workstation 32-bit, the other running Windows 10 Pro for Workstation 64-bit. (the 2004 version for both) I’ve disabled SecureBoot in the UEFI on both clients. I’ve run bcdedit /set TESTSIGNING ON, /set groupsize 2, and /set groupaware on, and rebooted for the settings to take effect.

On each client, I’ve set up several 2G partitions for testing: two NTFS, one FAT, one FAT32, one ExFAT, and one UDF. On the 64-bit machine, I’ve also set up a 10G ReFS volume with two physical drives.

On the server, in HLK I’ve selected our locally-developed driver and in Project selection, I’ve selected Filter.Driver.DeviceGuard, Filter.Driver.FileSystem, Filter.Driver.Fundamentals, and Filter.Driver.Security .

On the Windows 32-bit machine, all tests passed. However, on the Windows 64-bit machine, DataImageCoherencyTest under the Installable File System Filter Test is failing on the two NTFS partitions with the following error:

2524.B70 : +TEST+SEV2 : Test :DataImageCoherencyTest
Group :SectionsCaching
Status :C000004E (IFSTEST_TEST_STATISTICS_ERROR)
Description :{Msg# seccache!dtimgcoh!17} The first write statistic
was 0. The second 0. The number of bytes modified on
the file was 8704. It does not appear that all data
cached in the data section was flushed for the image
section.
WDKTUID: A72C4D26-977B-19CB-2E11-D6F93917D718
2524.B70 : +TEST+INFO : :: Status-Test: SectionsCaching:ExistingUserMappingTest
Status: 0x40000003 (IFSTEST_INFO_START_OF_TEST)

There was no such error on any of the other partitions.

I’ve re-run the tests on the 64-bit machine with NULL.SYS instead of our driver and I am getting exactly the same results. My (limited) understanding is that this probably indicates a hardware issue, is that correct? Or are there settings that I am missing somewhere?

On the theory that it was some hardware problem, I installed the 64-bit OS on the other client, where the Windows 32-bit tests had been completely successful. Running the tests on that 64-bit install, I had exactly the same DataImageCoherencyTest error occur on both NTFS partitions. Which makes me unsure that it’s actually a hardware issue.

More detail on the machines:

HLK Server – ASA RealPC, Xeon CPU E5-2620, 16 G RAM, 2 Western Digital 1 TB drives
HLK Studio Controller version 10.1.19041.19041, Studio version 10.1.19041.1
HLK Manager version 2.7.3521.0
Latest UpdateFilters.sql loaded

Clients:
HP Z240 tower, Core i7-6700 CPU, 32 G RAM, 2 Western Digital 1 TB drives
ASA RealPC, Core2 Quad CPU Q9550, 8 G RAM, 4 Samsung EVO SSD 1 TB drives
Both are running HLK Client version 10.1.19041.1
“Test mode Build 19041.vb_release.191206-1406” is in the lower right of the screen on both machines

When you got the same error with NULL.SYS was your driver still running? The tests really just pick the drives and not a specific driver, so you’re going to be involved no matter which driver you pick

I’m pretty sure the driver was not running – just to confirm, I uninstalled the driver, shut down and restarted the client, then ran the tests with NULL.SYS again, and got the same errors.

I extracted the test from the 2004 HLK and it ran just fine on my x64 system. So, sadly, it doesn’t appear as though the test is fundamentally broken. Any other third party software on the system?

I don’t know for sure, but based on the description it sounds like it’s doing cached writes to the file and then memory mapping for execute. If all is working the modified data should show up in the image section. Seems unlikely to be a hardware thing and more like a bug in an encryption or file virtualization filter (those are the ones most likely to play with sections like this)