I’m continuing to verify my driver through the Hardware Lab Kit, and a few of the tests are failing because they are timing out.
Specifically, these tests are failing with a timeout:
- DF - Concurrent Hardware And Operating System (CHAOS) Test (Development and Integration)
- DF - Concurrent Hardware And Operating System (CHAOS) Test (Reliability)
- DF - Fuzz zero length buffer IOCTL test (Reliability)
With that last one, it is hanging on this message:
WDTF_FUZZTEST : Running IOCTL Fuzzing Test on surface X. Access Mode=NO SYNC. Open Type=OTHER. Opened with access 1201bf
After a long time, the test will fail with:
Cause : INFORMATION: Task “Run Test” Failed Because the Task With TaskTimeout Flag Was running after the Timeout period 10800000 MilliSeconds
How can I go about debugging this?
The implication here is that your driver is not properly handling unrecognized ioctls. Is this a KMDF driver? If it’s WDF, you need to make sure you complete every request, even if you don’t recognize it. Otherwise, the ioctl remains pending, forever.
Also you can run with a debugger attached and use view the IFR logs from kmdf, and also the kmdfdb extension can show all the requests queued or owned by your driver.
@Mark_Roddy said:
Also you can run with a debugger attached and use view the IFR logs from kmdf, and also the kmdfdb extension can show all the requests queued or owned by your driver.
What is the kmdfdb extension that you’re referring to here? I can’t find anything online about it.
I’m running windbg remotely attached to the machine and I am DbgPrinting the IOCTLs out as they come but I’m not seeing anything getting hung up on a particular IOCTL - it seems to just continue chugging along, checking every IOCTL.
What is the kmdfdb extension that you’re referring to here? I can’t find anything online about it.
Sorry, it’s wdfkd. In windbg !wdfkd.help
Thanks for the information.
I found one IOCTL that appeared to be faulty, as it did not call the WdfRequestComplete function. Unfortunately when I re-ran the test, it still seemed to fail.
I re-ran the test, configuring with only 100 of the IOCTLs instead of the 4000+ that are in the default range. This new range covers some IOCTLs that are considered invalid by my driver, but far fewer than what would be in the default range. This passes the test.
I’m not sure how to proceed here, because it seems like the timeout issue is because the test takes longer than the allocated amount of time (15 minutes) to run.
I’m surprised that you would have any overlap with the fuzzer. How are you constructing your ioctl codes? Some people, especially those coming from Linux, have a tendency to start their ioctls with #1 and increase sequentially from there. That’s definitely a no-no in Windows, where the ioctl code consists of 4 different fields that all need real values.
@Tim_Roberts said:
I’m surprised that you would have any overlap with the fuzzer. How are you constructing your ioctl codes? Some people, especially those coming from Linux, have a tendency to start their ioctls with #1 and increase sequentially from there. That’s definitely a no-no in Windows, where the ioctl code consists of 4 different fields that all need real values.
I don’t think the issue is that there are ioctls that are overlapping. I have been using the CTL_CODE macro to set up my ioctls, with the function code going from 0x802 to 0x865 (with some gaps). Device type is always FILE_DEVICE_UNKNOWN and method is always METHOD_BUFFERED.
When I ran the HLK test “DF - Fuzz zero length buffer IOCTL test (Reliability)” with FunctionCodeStart from 2050 (0x802) to 2149 (0x865), it succeeded. Prior to this, I was running it with the default range of 0 to 4096, and it failed each time due to timeouts. The driver didn’t change between these runs.
On an unrelated note, I’m also failing both of the CHAOS tests due to timeout, though on one odd occasion it actually passed the test. It will shut down the machine and it sometimes doesn’t boot back up. There wasn’t a minidump file, so I don’t suspect a bluescreen occurred.
Hello,
I have the same issue with a driver that I am developing for Windows 10. This you find a solution to the problem?