none
Wdf01000.sys causes "DF - HyperVisor Code Inegrity Readiness Test" non-stop reboot of client RRS feed

  • Question

  • "DF - HyperVisor Code Inegrity Readiness Test" puts client into state of constant reboot for over 1-1/2 hour with error related to a Microsoft driver Wdf01000.sys instead of mine, even after host is disconnected. The only thing that got it back was to use recovery disk to go to command prompt and stop the verifier used by the kit.

    First pic is of host running the test, and second of the client prior to each reboot.

    Wednesday, May 11, 2016 6:32 PM

All replies

  • There isn't enough information here to identify what is causing the driver verifier violation and the bugcheck.

    Could you re-run the test with a kernel debugger attached? Alternately if you have a memory dump (probably stored under %WinDir%\MEMORY.DMP) could you load it in a debugger and examine the output from running "!analyze -v".

    Thursday, May 12, 2016 1:45 AM
  • Hi Tim,

    For the time being you can mention Filter #5792 in Readme doc to filter out this failure.

    https://sysdev.microsoft.com/en-US/Hardware/ec/FilterDetail.aspx?id=8651 

    Thanks,

    Arpo

    Thursday, May 12, 2016 6:57 AM
  • Hi Shyamal Varma,

    I am not sure how to run the debugger while the tests are running since the tests require the host/client, and the debugger a separate process running a host/target. And since the error is related to Microsoft's Wdf01000.sys file and I'm running the release build of Win10 (is there even a checked build?) with symbols only available for my checked build of my driver, not sure what useful information wold be available. So, not sure about how to do any of what you mentioned, except the dump file. How would only that, help except to let me know where the problem is within that Microsoft driver? 


    • Edited by TimConnect Thursday, May 12, 2016 12:44 PM
    Thursday, May 12, 2016 11:21 AM
  • Hi Arpo Adhikari

    Thanks for the reply. I followed the link you provided and all that is there is "DTM Filter Not Found." Support at sysdev.com also mentioned that filter but didn't tell me anything about it, just to open a ticket with Microsoft support (how much is a ticket these days - $500.00?) just to answer that one question related to a problematic Microsft driver interacting with the tests.

    Would you happen to have any other information about how to implement that filter and if it can be put in place without restarting two days worth of tests already running?

    Thanks,

    Tim

    Thursday, May 12, 2016 11:26 AM
  • Once you obtain a dump or attach a debugger to your system that is executing the tests, please share the output from "!analyze -v". Please see https://msdn.microsoft.com/en-us/library/windows/hardware/dn745912(v=vs.85).aspx for information on getting started with kernel debugging.
    You don't need a checked build, and the analysis would tell us which driver is responsible for the bug check. Wdf01000.sys is the KMDF library module and usually a driver verifier violation bug check associated with it, would be caused by another driver that is using KMDF.
    Friday, May 13, 2016 4:30 PM
  • Hi Shyamal,

    I was confused, since running a checked build of the OS was common back around 2003 when I first began developing a driver for our device to interact with the USB. In fact, doing so, I uncovered a bug in the Kernel, contacted Microsoft (was much easier by phone back then) and had a new build (freshly burned DVD from Microsoft developer in Redmond) in my hands in just a few days with the fix in place - that was really great service.

    But to be honest, I've hand't much need to do much driver debugging recently except when I setup a target/client machine and used WinDbg to step through the code of my driver on the client machine prior to running the tests, which worked pretty well.

    Anyhow, I was eventually able to get past the problem with that driver. I disconnected an external hub that was plugged into one of the ports and another USB device (neither of which I was intentionally testing) and the test succeeded. Perhaps, as you suggested, the Microsoft driver that showed the error was actually experiencing it due to a non-compliant driver it was interacting with.

    Thanks so much for taking the time to assist me in finding a solution.

    - Tim


    • Edited by TimConnect Friday, May 13, 2016 5:26 PM spelling correction
    Friday, May 13, 2016 5:16 PM
  • Hi Shyamal,

    We are running into exact same problem on both Windows 10 32bit and 64bit Client OSes. We have downloaded the latest HLK and Client OSes only yesterday. When trying to isolate the problem, we did not even install our driver. Instead we ran the HLK test on a pre-installed driver and even that failed the same way.

    So either there is a bug in WDF01000.SYS or some of the pre-installed drivers that come with standard Windows 10 OS.

    If we remove this test, all other test pass on our driver on both Windows 10 32bit and 64bit OSes.

    Can we submit the logs without even running the Hypervisor Code Integrity test ? Because if we run this, then we end up in an infinite cycle of BSODs till we can recover the system.

    Regards

    Thursday, June 30, 2016 2:25 PM