WiFi P2P connection fails occasionally

Question

WiFi P2P connection fails occasionally

Xiaojie Ma 30

Windows creates the WiFi Direct GO via the following code, a android device connect the go.

void WiFiDirect::Start()
{
	publisher = WiFiDirectAdvertisementPublisher();			    
	publisher.Advertisement().ListenStateDiscoverability(WiFiDirectAdvertisementListenStateDiscoverability::None);
	publisher.Advertisement().IsAutonomousGroupOwnerEnabled(true);
	publisherOnStatusChangedToken = publisher.StatusChanged({ get_weak(), &WiFiDirect::OnPublisherStatusChanged });
	publisher.Start();
}
void WiFiDirect::OnPublisherStatusChanged(WiFiDirectAdvertisementPublisher sender, WiFiDirectAdvertisementPublisherStatusChangedEventArgs args)
{
    XXXXX
	switch (args.Status())
	{
		case WiFiDirectAdvertisementPublisherStatus::Started:
		{
			try
			{
				listener = WiFiDirectConnectionListener();
				listenerOnConnectionRequestedToken = listener.ConnectionRequested({ get_weak(), &WiFiDirect::OnListenerConnectionRequested });
			}
			catch (winrt::hresult_error const& ex)
			{
				XXXXX
			}
			break;
		}
	}
}
void WiFiDirect::OnListenerConnectionRequested(WiFiDirectConnectionListener const& sender, WiFiDirectConnectionRequestedEventArgs const& args)
{
	try {
		auto lifetime = get_strong();
		auto client = args.GetConnectionRequest().DeviceInformation();
		WiFiDirectConnectionParameters params = WiFiDirectConnectionParameters();
		params.GroupOwnerIntent(15);
		WiFiDirectDevice wfdDevice = nullptr;
		int retry = 0;
		try
		{
			while (retry < 10)
			{
				retry++;
				auto asyncOperation = WiFiDirectDevice::FromIdAsync(client.Id(), params);
				auto aysncStatus = asyncOperation.wait_for(std::chrono::seconds(CONNECT_TIMEOUT));
				if (aysncStatus == AsyncStatus::Completed)
				{
					LogD(TAG, "Connect to %s successfully", clientName);
					wfdDevice = asyncOperation.GetResults();
					break;
				}
				if (aysncStatus == AsyncStatus::Started)
				{
					LogD(TAG, "Connect to %s timeout, cancel it.", clientName);
					asyncOperation.Cancel();
				}
				LogW(TAG, "Connect to %s fail, reason:%d", clientName, aysncStatus);
				Sleep(100);
			}
		}
		catch (hresult_error const& ex)
		{
			LogH(TAG, ex, "Wifi direct connect exception");
		}
		if (wfdDevice == nullptr)
		{
			LogW(TAG, "Connect to %ls fail", client.Name().c_str());
		}
		else
		{
			clientList.push_back(wfdDevice);
			wfdDevice.ConnectionStatusChanged({ get_weak(), &WiFiDirect::OnConnectionStatusChanged });
		}
	}
	catch (winrt::hresult_error const& ex) {
		LogH(TAG, ex, "OnListenerConnectionRequested exception");
	}
}

When the issue occurs, Provision Discovery exchange between Android and Windows works normally. Android scans and finds that WPS PBC on Windows remains inactive, blocking subsequent connection steps.

Meanwhile, Windows API WiFiDirectDevice::FromIdAsync(client.Id(), params) hangs and never completes.

This appears to be a Windows component issue. How to troubleshoot it?

0 comments

3 answers

Your answer

Answer 1

Use Windows wireless tracing to determine where the Wi‑Fi Direct connection flow breaks, then correlate that with the API hang.

Capture a wireless trace on the Windows device before reproducing the issue:

if not exist c:\tmp md c:\tmp
netsh trace start wireless_dbg capture=yes overwrite=yes maxsize=4096 tracefile=c:\tmp\wireless.etl

wireless_dbg is a legacy scenario that is still available. For new support cases, the documented preference is the TSS NET_WLAN scenario.

Reproduce the failure and record the exact time when:
- Android completes Provision Discovery
- Android shows WPS PBC on Windows as inactive
- WiFiDirectDevice::FromIdAsync(client.Id(), params) starts hanging
Stop and convert the trace:

netsh trace stop
netsh trace convert c:\tmp\wireless.etl

This produces wireless.etl, wireless.cab, and after conversion wireless.txt.

Analyze the ETW trace with TextAnalysisTool and start with the connection state machine:
- Apply the FSM transition filter first.
- Identify the last known good state before the failure.
- Windows Wi‑Fi connection states to look for are: Reset, Ihv_Configuring, Configuring, Associating, Authenticating, Connected, Roaming, Wait_For_Disconnected, and Disconnected.
If the failure occurs after the main state machine advances but before completion, inspect lower layers in the same trace:
- Enable FSM transition
- Enable SecMgr Transition
- Enable AuthMgr Transition
- Review Microsoft-Windows-WLAN-AutoConfig events immediately before the bad transition
Pay special attention to evidence that the failure is propagating up from lower wireless components. The documented example shows that a SecMgr Transition DEACTIVATE can propagate back to the main connection state machine, and that tracing backward can reveal a Received IHV PORT DOWN event. That pattern indicates the issue may be closer to the wireless hardware, miniport, or lower Native Wi‑Fi stack rather than only the app layer.
Since the hang occurs in WiFiDirectDevice::FromIdAsync(...), also verify the Wi‑Fi Direct prerequisites on Windows:
- Wi‑Fi Direct support for desktop apps is in the Native Wifi API starting with Windows 8 / Windows Server 2012.
- For desktop apps, Wi‑Fi Direct devices must be paired first through the Windows pairing UI so that a stored profile exists and a Wi‑Fi Direct session can be started.
- The Native Wifi Wi‑Fi Direct flow includes opening a handle/session with functions such as WFDOpenHandle, WFDOpenLegacySession, and closing/canceling with WFDCloseSession, WFDCancelOpenSession, and WFDCloseHandle.
If the issue is intermittent, compare a good trace and a bad trace at the same phase:
- Find the last matching state in both traces.
- Then compare the next Microsoft-Windows-WLAN-AutoConfig, SecMgr, and AuthMgr events.
- This usually isolates whether the break happens during configuration, association, authentication, or due to a lower-layer port event.
Rule out common platform causes on the affected Windows client:
- Restart the WLAN AutoConfig service (WlanSvc).
- Remove third-party connection managers if present.
- Check whether client policy or recent updates correlate with the failures.

If the trace shows the connection flow stopping after Provision Discovery with no progress beyond the relevant WLAN state transition, the most useful evidence is the ETW sequence immediately before the stall, especially any Microsoft-Windows-WLAN-AutoConfig, SecMgr/AuthMgr, or port-down indications.

Answer 2

Deleted

This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Comments have been turned off. Learn more

Answer 3

Gatlin Le (WICLOUD CORPORATION) 1,065 Microsoft External Staff Moderator

Hi @Xiaojie Ma ,

Thanks for checking the Android side. PD completing while Windows WPS PBC remains inactive helps narrow the investigation, but does not confirm the cause. A Windows wireless ETW trace is the next step.

Following Microsoft's trace collection guidance, capture the failure before changing code or restarting wireless services:

Open Command Prompt as administrator and change to an existing folder where you want to keep the trace. Start tracing before the publisher and connection attempt:
```
   netsh trace start wireless_dbg capture=yes overwrite=no maxsize=4096 tracefile=failure.etl
```
wireless_dbg remains available despite being a legacy scenario omitted from netsh trace show scenarios. Use a new filename if the file exists, and confirm tracing started.
Reproduce the issue. Record ConnectionRequested, PD/PBC, and timeout/cancellation timestamps, accounting for clock differences. Log before and after FromIdAsync to distinguish a blocked call from a returned operation that remains Started.
Stop tracing after capturing the failure:
```
   netsh trace stop
```
Keep the output files. If possible, capture a successful attempt separately as success.etl with unchanged settings. For an optional text version, run netsh trace convert failure.etl from the same folder.

For new Microsoft Support cases, the guidance prefers the TSS NET_WLAN scenario.

Your logged aysncStatus comes from before Cancel(). Log the current Status() and, if it is Error, the HRESULT from ErrorCode().

After capturing the original failure, test without automatic retries while keeping other settings unchanged. This is a diagnostic comparison, not a confirmed fix. Microsoft's Advertiser sample also illustrates incoming-request handling, pairing, and FromIdAsync.

Please confirm whether the failure occurs on the first attempt, before any cancellation, or only afterward. Include a short, timestamped Status()/HRESULT excerpt with identifiers redacted.

Include the Windows build and adapter/driver version if available. Share full traces only through a private support channel, as they may contain network identifiers and traffic.

If you found my explanation above was truly helpful or informative to you, I would greatly appreciate it if you could follow this guidance so others with the same issue could benefit as well.

Xiaojie Ma 30 Reputation points

2026-10-13T03:26:06.38+00:00
Hi @Gatlin Le (WICLOUD CORPORATION)

Thank you for the guidance. I will follow your steps to reproduce the issue and disable automatic retries for testing. Before capturing traces, I’d like to share some available information:

Our code waits up to 6 seconds for WiFiDirectDevice::FromIdAsync to complete. If it finishes within 6s, the flow proceeds normally. If the async operation remains in the Started state after the 6-second timeout, we cancel it and retry in a loop. When this bug occurs, the very first call to WiFiDirectDevice::FromIdAsync hangs and does not complete within 6 seconds. Even after cancellation, subsequent retries of FromIdAsync still cannot finish normally.

OS build: Windows 26H2 (26300.9550). Wi-Fi adapter: RTL8922AE, driver version 6102.24.108.349.

This issue is intermittent with low reproduction rate. I will use our automated test program to reproduce it, which may take a long time. I will share the ETW traces once captured.

Thanks
Gatlin Le (WICLOUD CORPORATION) 1,065 Reputation points Microsoft External Staff Moderator

2026-10-13T04:01:09.44+00:00

Hi @Xiaojie Ma ,

Thanks for the build and driver details, and for arranging the automated test. I understand that capturing this infrequent issue may take time.

The first FromIdAsync operation already exceeds 6 seconds, so retries do not explain the initial delay in that attempt. The 6-second limit is your application's cutoff: Started means the operation is still pending, not necessarily permanently stuck. Microsoft's C++/WinRT timeout guidance explains this distinction.

With retries disabled, keep the 6-second marker in the log. If feasible, observe the same operation longer before cancelling, for example up to 60 seconds total from its start. Record whether it completes, errors, or remains Started. Use Status() rather than calling wait_for again, and do not start another attempt while it remains pending. Alternatively, for this run only, a single longer wait with the elapsed time logged at completion gives the same information. The 60 seconds is only a diagnostic window; it is not an API-defined timeout or a confirmed fix. If changing cancellation is impractical, the original 6-second failure trace is still useful.

Pause further attempts and run netsh trace stop after that observation, before restarting the app or adapter. Monitor disk space during long runs: capture=yes can generate large files quickly. If tracing uses fileMode=circular, older events are overwritten when the file reaches maxSize, so save the capture promptly. These behaviors are described in the netsh trace documentation.

When available, share a short, redacted timestamp/status excerpt showing the outcome. Keep the full ETW files for a private support channel.