Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


HLK - Tests time out

nwhitlockeizonwhitlockeizo Member Posts: 7

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?

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,832

    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.

    Tim Roberts, [email protected]
    Software Wizard Emeritus

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,753

    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.

  • nwhitlockeizonwhitlockeizo Member Posts: 7

    @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.

  • Mark_RoddyMark_Roddy Member - All Emails Posts: 4,753

    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

  • nwhitlockeizonwhitlockeizo Member Posts: 7

    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.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,832

    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, [email protected]
    Software Wizard Emeritus

  • nwhitlockeizonwhitlockeizo Member Posts: 7

    @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.

  • SanderAcQSanderAcQ Member Posts: 2

    Hello,
    I have the same issue with a driver that I am developing for Windows 10. This you find a solution to the problem?

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online