HLK 25H2: Wi-Fi Direct test stuck at "Run Test" / "Start RemoteServer on SUT" – client completed but controller not receiving status

Question

HLK 25H2: Wi-Fi Direct test stuck at "Run Test" / "Start RemoteServer on SUT" – client completed but controller not receiving status

Peng DENG 0

Environment:

Windows HLK version: 25H2
Test machines: TEST4 (DUT) and TEST1 (SUT), both in machine pool WIFIV1560, Runtime Version 2.7.3539.0
Test name: Wi-Fi Direct Service Pairing and Reconnect Tests - Functional
Job ID: 1270
Log path: \\WIN-0H9B61J5LGD\HLKLogs\3-3-2026\028C5905-6131-47F6-B959-F7E1172D4D6E

Issue:

User's image

When running the above test, the job status in HLK Controller remains InProgress indefinitely, stuck on two sub-tasks:

Run Test
Start RemoteServer on SUT

The test process on both DUT and SUT has actually finished and exited, but the HLK Controller never receives the completion or failure status. This has caused multiple duplicate jobs with the same Job ID to be scheduled.

Steps already tried:

Verified HLK Client Service is running on DUT/SUT.
Confirmed network connectivity between DUT/SUT and Controller (ping works).
Canceled stuck jobs in HLK Controller and re-scheduled, but the issue persists.

Questions:

What are the common root causes for test completion on clients but no status update on the HLK Controller?
Are there more reliable methods to restore the stuck test communication, besides manually terminating processes?

Peng DENG 0 Reputation points

2026-03-05T01:31:39.2966667+00:00

Do you have any update?

1 answer

Your answer

Peng DENG 0 Reputation points

2026-03-05T01:31:39.2966667+00:00

Do you have any update?

Answer 1

Tom Tran (WICLOUD CORPORATION) 4,580 Microsoft External Staff Moderator

Hi @Peng DENG ,

Thank you for the detailed description and the screenshot.

Based on your description, the problem is that the HLK Controller never updates its state, so it stays stuck on “Run Test” and “Start RemoteServer on SUT” even though nothing is running anymore. This usually means the controller lost track of the job, not that the Wi‑Fi Direct test failed.

In HLK, the clients run the test, but the controller is the one that decides when a job is done. When that final status doesn’t get through, the job can sit in InProgress forever, and re‑running it can create duplicate jobs with the same Job ID. At that point, re‑scheduling the test usually doesn’t help and can make things messier.

I’d recommend focusing on getting the controller and clients back into sync before running the test again:

Restart the HLK Client service (wttsvc) on both machines.
Reset the DUT and SUT in HLK Manager and wait until they’re fully back in Ready.
Run the test once, by itself, with no other jobs using the same machine pool.

This kind of behavior is generally treated as an HLK infrastructure issue, not a problem with the Wi‑Fi Direct test logic itself. Microsoft’s HLK troubleshooting guidance also points out that when job status doesn’t update correctly, resetting the environment is the right recovery step rather than repeatedly re‑running the test:

https://learn.microsoft.com/windows-hardware/test/hlk/user/troubleshooting-windows-hlk-client

If the controller still gets stuck after a clean reset and a single re‑run, that would suggest a broader HLK environment issue rather than anything specific to this test.

If you found my response helpful or informative, I would greatly appreciate it if you could follow this guidance provide feedback. Thank you.

Peng DENG 0 Reputation points

2026-03-05T04:09:53.23+00:00

hi Tom Tran (WICLOUD CORPORATION)

I have create new pool for DUT/SUT/AP, and restart HLK services as below.

and just plan one case to run, but DUT status still cannot report the controller.

Are there more reliable methods to restore the stuck test communication?
Tom Tran (WICLOUD CORPORATION) 4,580 Reputation points Microsoft External Staff Moderator

2026-03-05T06:53:07.8533333+00:00
Hi @Peng DENG ,

Thanks for the update and the screenshots.

From what you’re showing, the test steps on the client side did actually run and finish (the Start RemoteServer on SUT step has both a start and end time). So this doesn’t look like the test hanging. Instead, it looks like the HLK Controller never picked up the final result from the client, which is why the job stays stuck afterward.

Since the environment reset and re‑pooling have already been tried, the next thing to focus on is the communication path between the HLK clients and the controller itself.

A few things that are worth double‑checking in this situation:

Make sure TCP port 1771 is open between the controller and all HLK clients. HLK uses this for controller‑client communication, and if it’s blocked or filtered, the controller may never receive the completion message.

Check that IPsec settings are consistent across all machines (either enabled everywhere or disabled everywhere).

If these systems are VMs or were cloned, confirm they’re uniquely identified. Duplicate MAC addresses or SMBIOS UUIDs can cause the controller to confuse clients.

If all of that looks good, the next step would be to look at the HLK infrastructure logs to see what happens when the client tries to report the result and why the controller doesn’t update the job state.

If you can, please share:

HLK Controller logs from C:\Program Files\Windows Kits\10\Hardware Lab Kit\Controller\Logs

HLK Client logs from both the DUT and SUT

The job log folder you mentioned earlier
Peng DENG 0 Reputation points

2026-03-09T03:38:18.03+00:00
Hi Tom Tran (WICLOUD CORPORATION) :

Below items check result as below:

Make sure TCP port 1771 is open between the controller and all HLK clients. HLK uses this for controller‑client communication, and if it’s blocked or filtered, the controller may never receive the completion message. ---- 1771 port of controller and all HLK clients are opened.

Check that IPsec settings are consistent across all machines (either enabled everywhere or disabled everywhere). ----Controller and all HLK clients IPsec settings are disabled

If these systems are VMs or were cloned, confirm they’re uniquely identified. Duplicate MAC addresses or SMBIOS UUIDs can cause the controller to confuse clients. ------Controller and all HLK clients are not VMs or cloned

If you can, please share:

HLK Controller logs from C:\Program Files\Windows Kits\10\Hardware Lab Kit\Controller\Logs ----There is no logs folder in Controller

HLK Client logs from both the DUT and SUT Which log do you want me to provide?
Peng DENG 0 Reputation points

2026-03-10T06:41:14.1033333+00:00

Do you have any update ?
Tom Tran (WICLOUD CORPORATION) 4,580 Reputation points Microsoft External Staff Moderator

2026-03-10T10:29:07.6466667+00:00
Hi @Peng DENG ,

Thanks for checking those items and sharing the screenshots.

Since the network checks, IPsec settings, and machine identity all look correct, the next step is to check the HLK logs to see why the controller is not receiving the final test result from the client.

From the screenshots, the test appears to run and finish on the client, but the controller never updates the job status. This usually means the message from the HLK Client to the HLK Controller did not get delivered. Issues like communication problems or client configuration problems can cause this behavior.

Could you please share the following files:

From the DUT and SUT

C:\HLK\JobsWorkingDir\HLKSvc.log

Also please check this folder and let us know what files are inside

C:\HLK\JobsWorkingDir\pendingMessages

From the HLK Controller

C:\Program Files (x86)\Windows Kits\10\Hardware Lab Kit\Controller\WTTSystemLogs

Share via

HLK 25H2: Wi-Fi Direct test stuck at "Run Test" / "Start RemoteServer on SUT" – client completed but controller not receiving status

1 answer

Your answer