Intermittent Wi-Fi connectivity loss after using WSL2 (Intel AX211) - adapter remains connected but cannot reach gateway

[Kitipali]

Windows Version

Microsoft Windows [Version 10.0.26200.8894]

WSL Version

2.7.10.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

6.18.33.2-2

Distro Version

Ubuntu 24.04.3 LTS (Noble Numbat)

Other Software

Jupyter Notebook / JupyterLab (although the issue also occurs when only using the WSL shell).

Repro Steps

1. Boot Windows normally.
2. Start Ubuntu under WSL2.
3. Use WSL for some time. Sometimes I only use the shell, sometimes I run Jupyter Notebook.
4. After an unpredictable amount of time, Wi-Fi connectivity is lost.
5. The issue is intermittent, but recently it has become much more frequent (3-4 times in a single morning).
6. Rebooting Windows always restores connectivity.

Expected Behavior

Wi-Fi connectivity should remain stable while using WSL2.

Actual Behavior

Hardware:

• Laptop: HP OMEN 16
• Wireless adapter: Intel(R) Wi-Fi 6E AX211 160MHz

When the issue occurs:

• Windows still shows the Intel AX211 adapter as connected.
• The adapter remains in the "Up" state.
• The IP address, default gateway and DNS servers are still assigned.
• Ping to the local gateway fails (100% packet loss).
• Internet connectivity is completely lost.
• "netsh wlan show interfaces" hangs indefinitely.
• "Disable-NetAdapter -Name Wi-Fi" hangs indefinitely.
• "Get-NetAdapterStatistics" returns successfully.
• HNS service is still running.
• vmcompute is still running.
• "wsl --status" still responds normally.
• The only reliable recovery is rebooting Windows.

Diagnostic Logs

The following troubleshooting steps have already been performed:

• Tested with the latest Intel Wi-Fi driver.
• Tested with the HP-provided Wi-Fi driver.
• Repaired Windows using the Windows Update repair option.
• Disabled Wi-Fi 6 by forcing the adapter to use 802.11ac only.
• Previously tested networkingMode=mirrored with dnsTunneling=true.
• The problem still occurs.

Additional observations:

• The issue initially seemed related to Jupyter, but it also occurs when only using the WSL shell.
• HNS and vmcompute continue running after connectivity is lost.
• WSL itself continues working normally.
• The adapter appears connected but cannot even reach the local router.
• The issue has become significantly more frequent. Initially it was difficult to reproduce, but it is now occurring several times per morning while using WSL2. This has made it much easier to reproduce the problem.

[github-actions]

Logs are required for review from WSL team

If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.

How to collect WSL logs

Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use .\collect-wsl-logs.ps1 -LogProfile networking instead, following the instructions in Collect WSL logs for networking issues

Once completed please upload the output files to this GitHub issue.

See Collect WSL logs (recommended method).

If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.

[Kitipali]

WslLogs-2026-07-29_09-04-53.tar.gz

I reproduced the Wi-Fi issue while the log collection script was running. The requested WSL logs are attached.

After collecting the logs, Windows crashed during restart with a DRIVER_POWER_STATE_FAILURE (Bug Check 0x9F). The system remained stuck at 0% while collecting crash data for more than 10 minutes and required a forced power off.

One additional observation: Internet connectivity is lost first while Windows still shows the Wi-Fi connection as active. A short time later, the Wi-Fi icon disappears from the taskbar.

The issue has also become much more frequent over the last few days and now reproduces almost every morning shortly after I start using WSL.

[github-actions]

Diagnostic information

Detected appx version: 2.7.10.0

[Kitipali]

WinDbg analysis of a minidump from the same issue shows:

DRIVER_POWER_STATE_FAILURE (0x9F), Arg1 = 3.

The blocked power IRP is in:
\Driver\Netwtw14

Device stack:
\Driver\vwifibus
\Driver\Netwtw14
\Driver\ACPI
\Driver\pci

Device service:
Netwtw14

PCI ID:
PCI\VEN_8086&DEV_7A70&SUBSYS_00948086&REV_11

This strongly suggests that the Intel Wi-Fi driver becomes stuck during a power transition, possibly after interaction with WSL/Hyper-V virtual networking.

[Kitipali]

Please find the Intel System Support Utility (SSU) report attached.

Detailed-System-Report.html

[shuaiyuanxx]

@Kitipali Thanks for the logs. WSL NAT/HNS network creation completes successfully; the strongest signal remains the blocked power IRP in Intel's Netwtw14 driver.

Could you provide:

1. !analyze -v, !irp, and !devstack from the dump
2. The Intel AX211 driver version
3. A networking log captured through the failure:
   collect-wsl-logs.ps1 -LogProfile networking -RestartWslReproMode
4. Whether it reproduces with networkingMode=none

If it still occurs with networking disabled, this likely belongs to the host Wi-Fi driver/platform path rather than WSL networking.

[Kitipali]

Hi Shawn, Thank you for reviewing the logs. Please find below the requested WinDbg outputs from the crash dump. ### 1. !analyze -v DRIVER_POWER_STATE_FAILURE (9f) A driver has failed to complete a power IRP within a specific time. Arguments: Arg1: 0000000000000003, A device object has been blocking an IRP for too long a time Arg2: ffffc50739299360, Physical Device Object of the stack Arg3: ffffc288ca1679f0, nt!TRIAGE_9F_POWER Arg4: ffffc50741b84b20, The blocked IRP ### 2. !irp

[IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)]

\Driver\Netwtw14 [IRP_MJ_POWER(16), IRP_MN_SET_POWER(2)] \Driver\vwifibus ### 3. !devstack !DevObj !DrvObj \Driver\vwifibus \Driver\Netwtw14 \Driver\ACPI \Driver\pci Device: PCI\VEN_8086&DEV_7A70&SUBSYS_00948086&REV_11 ServiceName: Netwtw14 Intel AX211 driver version currently installed: 23.120.0.3 (HP-certified driver) Before installing the HP-certified driver, I was using the latest Intel driver available at that time. The issue was also reproducible with that Intel driver, which is why I downgraded to the HP-certified version as part of the troubleshooting process. The issue is intermittent. Today I used both WSL and Jupyter without any connectivity problems, so I will perform the requested networking log capture and test `networkingMode=none` the next time the issue reproduces. Best regards, Juan Francisco Barragán El jue, 30 jul 2026 a las 9:15, Shawn Yuan ***@***.***>) escribió:

…

*shuaiyuanxx* left a comment (microsoft/WSL#41194) <#41194 (comment)> @Kitipali <https://github.com/Kitipali> Thanks for the logs. WSL NAT/HNS network creation completes successfully; the strongest signal remains the blocked power IRP in Intel's Netwtw14 driver. Could you provide: 1. !analyze -v, !irp, and !devstack from the dump 2. The Intel AX211 driver version 3. A networking log captured through the failure: collect-wsl-logs.ps1 -LogProfile networking -RestartWslReproMode 4. Whether it reproduces with networkingMode=none If it still occurs with networking disabled, this likely belongs to the host Wi-Fi driver/platform path rather than WSL networking. — Reply to this email directly, view it on GitHub <#41194?email_source=notifications&email_token=BO5SPKD5RT4P6SHEKNQP4VD5HL7ZXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMJSHAZTENJWGA2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5128325604>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BO5SPKCXKJXPKVCFPBUZJWD5HL7ZXAVCNFSNUABEKJSXA33TNF2G64TZHM2TKNRSGY4TGNJ3JFZXG5LFHM2DSOJXGE3DKNZYGCQXMAQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>