HLK HyperVisor Code Integrity Readiness Test issues before actually testing

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…

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.

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! :wink: Often it is easier to search “something msdn” at google than directly at msdn…

Rafael

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

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.

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! :wink: Often it is easier to search “something msdn” at google than directly at msdn…

Rafael

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!

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.

Dear All,
I have the same problem. Latest VHLK test server and test client WIN10. All tests succeed except Code Integrity Readiness Test. Everything is identical to __rs description. I have also downloaded and applied the latest filter. VS2019 Code Analysis and Static Driver Verifier do not report errors. The log file Te.wtl says: Error code 0x0 (sound good?) File: base\ci\tests\kits\hvci\hvcihlktest.cpp Line 358 and HvciHlkTest::HvciTest failed. So far as I understand this, is it not a failure in the test driver, but in the HLK. I have not understand __rs solution " I just put a stub exe there". What do you mean here? And if MS checks the submitted Package do they not get the same errors as I got? And btw. I found a note on social.msdn… “Please note that the ‘HyperVisor Code Integrity Readiness Test’ is not in the official Windows Hardware Compatibility Program Playlist so it is not required for driver submission.”, dated 2015 however.

Can anyone help me with this issue?
WDDriver

You know you’re necroposting, right? You’re tacking your own issue onto a thread that’s a year old.

Start a new thread with your question. Please. If you want, point to the thread that you just posted to.

Peter