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

Home NTDEV

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/


Before Posting...

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

HLK HyperVisor Code Integrity Readiness Test issues before actually testing

__rs__rs Member Posts: 5
edited June 18 in NTDEV

Hi there!

I have been facing a weird issue with HLK HyperVisor Code Integrity Readiness Test. Before running HLK suites I tested against driver verifier and Code integrity did not report me any issue. I am not using any NonPagedPool reference into my driver, too. The point is that when HLK hits HyperVisor Code Integrity Readiness Test at the step "EnableDriverVerifierWaitForShellReady-ProxyClient" it has been failing. Thus with it I have no clue of what can be happen because Logs are only generated when the test actually runs. It seems to be an internal error that only who has automated this stuff could understand. I have updated HLK filters, too. But nothing.

Moreover, I gave a try to DGReadiness Tool. It did not report me any problem with my driver.

The detail is that I have using the evaluation edition image for HLK server (but it is still valid for evaluation).

I would be grateful if someone give me a clue of what could be happen. All other tests seem to be passing and generating their logs normally.

Thanks in advance!
Rafael

PS: HLK testing process is a pain in the neck! It should be more transparent to the developer, sometimes it looks like a rube goldberg machine, but this is not the case here... The intent seems really good but the way of it is done need to be improved. The HLK Studio interface is a little bit buggy, too...

Comments

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,086

    How does it fail? There must be some kind of message.

    HLK testing process is a pain in the neck!

    Always has been, always will be. Remember, this process was invented in order to test Windows itself, where they have a dedicated staff controlling many hundreds of systems. The learning curve in that case is irrelevant, but when you have one server testing one client, it is daunting.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • __rs__rs Member Posts: 5

    Thanks for replying Tim! The lack of a detailed failure message is being the most difficult part for me. The only thing that I am able to see and figure out that it has been failed is through Results page at HLK Studio. However, as I have been said, the failure happen at the test setup (at least is what I understand) and at this point there is no log to gather at the test machine to give me more clues.

    The last thing well-succeeded (checked with a green "V") in Hypervisor tests was "EnableDriverVerifierReboot-ProxyClient". After, all steps ("EnabledDriverVerifierWaitForShellReady-ProxyClient", "StartWriteDriverVerifierLog", "WaitWriteDriverVerifierLog", "StopDriverVerifierLog", "Run Test" and "DisableDriverVerifier") are marked with a red "X" signaling that they were aborted by the first failure (when executing step "EnabledDriverVerifierWaitForShellReady-ProxyClient").

    I guess that a useful log if the problem was really caused by my driver would be produced only after "Run Test" step. In this way, it would collect the result and present me a "Test Log" to click and see more details. Anyway, it was not able to get there.

    Yes, the problem with HLK is that sometimes it seems to much specialized, it could be more cooked for developers outside from MS. Because this kind of failure must be meaningful to a person that works with MS code base everyday (a.k.a ms employees that do kernel test), but someone that only uses API/WDK etc on a proprietary kernel is kind of tough task to guess up some not documented incantations. Searching the reason of failure on msdn is another problem, the documentation is sparse and seems to be written/organized by Daedalus! ;) Often it is easier to search "something msdn" at google than directly at msdn...

    Rafael

  • __rs__rs Member Posts: 5

    Additional detail: I also did a poC with beep.sys and the same bad results for hypervisor readiness tests happen with it.

  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,086

    I shouldn't give you false hopes, but there are hundreds (or thousands) of known false positives in the HLK tests. Microsoft has a set of exception filters for those false positives, so you can still submit the logs. Check https://docs.microsoft.com/en-us/windows-hardware/test/hlk/user/windows-hardware-lab-kit-filters and see if it helps.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • __rs__rs Member Posts: 5

    Thanks for replying Tim! The lack of a detailed failure message is being the most difficult part for me. The only thing that I am able to see and figure out that it has been failed is through Results page at HLK Studio. However, as I have been said, the failure happen at the test setup (at least is what I understand) and at this point there is no log to gather at the test machine to give me more clues.

    The last thing well-succeeded (checked with a green "V") in Hypervisor tests was "EnableDriverVerifierReboot-ProxyClient". After, all steps ("EnabledDriverVerifierWaitForShellReady-ProxyClient", "StartWriteDriverVerifierLog", "WaitWriteDriverVerifierLog", "StopDriverVerifierLog", "Run Test" and "DisableDriverVerifier") are marked with a red "X" signaling that they were aborted by the first failure (when executing step "EnabledDriverVerifierWaitForShellReady-ProxyClient").

    I guess that a useful log if the problem was really caused by my driver would be produced only after "Run Test" step. In this way, it would collect the result and present me a "Test Log" to click and see more details. Anyway, it was not able to get there.

    Yes, the problem with HLK is that sometimes it seems to much specialized, it could be more cooked for developers outside from MS. Because this kind of failure must be ordinary for a person that works with MS code base everyday (a.k.a ms employees that do kernel test), but someone that only uses API/WDK etc on a proprietary kernel is kind of tough task to guess up some not documented incantation. Searching the reason of failure on msdn is another problem, the documentation is sparse and seems to be written/organized by Daedalus! ;) Often it is easier to search "something msdn" at google than directly at msdn...

    Rafael

  • __rs__rs Member Posts: 5
    edited June 22

    Hi Tim! I have tried those filters later but without success. The only way that I could make this test pass was keeping logged in the client machine (during the related problematic test step). After that, I waited there for HVCI window log, it shows up quickly and exits, after it reboots. Then I close the VM window and it has passed. Some passes related to WFP drivers are also problematic: https://social.msdn.microsoft.com/Forums/en-US/210048e2-be1b-4dc8-825e-050f5e29b439/cant-find-startappcontainerexe?forum=whck I faced this problem, too. I googled about this application and nothing. Tired, I bluffed: I just put a stub exe there, re-run the test and I have done. Some tests are really messy... Thanks anyway, for your support!

  • Ivan_AndreyevIvan_Andreyev Member Posts: 2

    Hello!

    We had similar issue. Per our investigation in some circumstance test does not complete tasks status update on controller before system reboot it schedules. After system reboot it looses completed tasks state and will not update them on controller.

    In our case reason was in delays during name resolution. This test makes many name resolution queries for controller ip although we can see in logs in caches its ip address.

    After we fixed name resolution issue in our test lab test now work as expected and completes successfully.

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!
Internals & Software Drivers 15 November 2021 Live, Online
Writing WDF Drivers TBD Live, Online
Developing Minifilters 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online