I am trying to get my WDM Virtual Storport Miniport through the HLK tests. It simulates a USB drive based on an image file. The location of the image file is communicated to the driver by IOCTLs. When the driver opens the path with ZwCreateFile or IoCreateFile, HLK tests fail with the issue that the driver must not used absolute paths for opening files. So basically all tests causing the drive to eject and open again are affected.
For a file backed virtual disk I do not understand what Microsoft expects me to do here. Does anybody faces a similar issue and found a solution?
Interesting! The goal of this verification is to prevent hardcoded paths within drivers, but it being specified to the driver via IOCTL presumably looks the same to driver verifier.
You can request an errata for this, or if you wanted to make a change to work better with driver isolation guidelines, it should work fine if you made it so all the files were under \DriverData
Thanks for your insights. Yes, I am thinking the same, especially since I need to store the path to open the file when I am guaranteed to be in the passive IRQL.
Putting all the images under a fixed location under C:\Windows\System32\drivers\DriverData (this is where DriverData points to) is not an option. I would like to see the reactions if Microsoft decides that all users can only create their VHDs in this folder on the C drive only
This issue seems too major to me, since this would mean anybody who writes a file backed virtual device must run into this issue at some point. However I did not find a big yelp, yet. So I assume I am doing something wrong. But I will also look into the topic on how to request an errata.
I googled a bit, and it seems that this is a part of the driver isolation concept Microsoft decided to enforce.
Apparently, the drivers should never access arbitrary files, but only those that “belong” to the driver and located inside the driver-specific path obtained via IoGetDeviceDirectory().
From what I’ve read, it’s enforced on Windows Drivers, but not on Windows Desktop Drivers, so if you’re not targeting server OS versions it should still work (but don’t quote me on that). And no, that document does not answer the question about what a developer should do if the driver does need to access an arbitrary file.
@Dejan_Maksimovic I am positive that the error message is correct. I also went through this error message for registry paths and logging paths. So removing absolute paths for logs (which makes sense) fixed this issue. I will try to switch from \\DosDevices\\ to \\??\\. At least Master AI claims it might also bring performance boost
@CaptainFlint Thanks for this page. I also understand that the isolation is not enforced for Windows Desktop Drivers. I checked my MSVS project, but driver settings there were already specified for a Desktop driver. But I will try to play around with these options.
I use HLK for Windows 11, version 25H2. The target OS, if my understanding is correct, is Windows 10.0.26100. My WDK version is 10.0.28000 and I am building with MSVS 2026. Maybe I should downgrade…
By target I meant the client machines in the HLK tests. But I guess they are Win11 25H2, to fit the HLK version?
I don’t think downgrading WDK will help. The tests checks the actual behavior of the driver in the specific client OS, it doesn’t matter what version the driver was built for.
In that case errata sounds more and more like the only option. Well, apart from abandoning HLK and going with Attestation, obviously.
