Changes between Version 37 and Version 38 of HLKTesting

Timestamp:

06/14/19 06:43:50 (5 years ago)

Author:

Samuli Seppänen

Comment:

--

HLKTesting

@@ -27 +27 @@
 as described in MS documentation.
 
-
 According to practical testing done by [https://www.wintun.net/ wintun] developers it is possible to get a code signature that is valid for all Windows 10 platforms using the following HLK clients:
 
@@ -47 +46 @@
 There are some additional requirements for tap-windows6 that stem from generic [https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/lan-testing-prerequisites LAN testing prerequisites]:
 
-* HLK client needs at least 4 virtual processor cores (unverified)
+* HLK client needs at least 4 virtual processor cores (unverified) for Windows Server certification
 * HLK clients need to be physical computers, not virtualized (unverified)
 
@@ -71 +70 @@
 
 Make sure to get the HLK Hardware Compatibility Playlists (on the main HLK download page), and apply the one for the correct context, e.g. HLK Version 1809 CompatPlaylist x64 Server.xml. The playlist narrows down the list of tests to the set required to get an HLK certification, removes some extra stress/failure verification type tests designed to help find driver crashes. There’s a “Load Playlist” option in the tests panel in the HLK studio app that you can use.
-
 
 = Setting up OpenVPN for HLK tests =
@@ -220 +218 @@
 Reboot and ping each host to make sure everything is working. You are now setup to run the WHQL tests. Some of them need babysitting and are listed below:
 
-1c_FaultHandling, At the end of the test the Service might not re-establish a link. WHQL seems to get the OpenVPN service into a bad state, just restart the OpenVPN service and the test will pass. The test waits a few minutes for the link to come back up.
-
-2c_Mini6Stress, Sometimes this test will hit a breakpoint in the NDIS test code. The breakpoint seems harmless and complained about some packets not getting confirmed. If you don't connect a kernel debugger this will cause a BugCheck and the test will fail. If this happens connect a kernel debugger and rerun the test. When the breakpoint is hit press (l) Always Ignore and the test will pass.
-
-2c_Priority, Follow the directions for using tapdiag in this document.
-
-
-
 In general the rest of the tests passed without a problem. However, it was more successful doing groups at a time and making sure they passed.
 
@@ -285 +275 @@
 == NDISTest 6.0 - 2 Machine - 2c_Priority ==
 
-
 Use Tapdiag to enable 802.1Q on both machines before running the NDIS QoS test (2c_Priority). 
 
@@ -310 +299 @@
 
 This is a problem if the support machine has an old tap-windows6 driver version that claims to be 100Mbps whereas the device under test ("DUT") is advertising itself as 1Gbps device. Resolve by installing the correct (1Gbps) tap-windows6 driver version to the support machine as well.
+
+== NDISTest 6.0 - 1 machine - 1c_FaultHandling ==
+
+At the end of the test the Service might not re-establish a link. WHQL seems to get the OpenVPN service into a bad state, just restart the OpenVPN service and the test will pass. The test waits a few minutes for the link to come back up.
+
+== NDISTest 6.0 - 2 machine - 2c_Mini6Stress ==
+
+Sometimes this test will hit a breakpoint in the NDIS test code. The breakpoint seems harmless and complained about some packets not getting confirmed. If you don't connect a kernel debugger this will cause a BugCheck and the test will fail. If this happens connect a kernel debugger and rerun the test. When the breakpoint is hit press (l) Always Ignore and the test will pass.
+
+You may also get away with just rerunning the test until it passes.
 
 == Cable unplug test ==