Diagnosing netvsc Kernel Panics in WSL2 Mirrored Mode

by

A network outage after enabling networkingMode=mirrored in WSL2 is not automatically a netvsc kernel panic. If the WSL shell remains usable and only a particular port fails, inspect application binding, the Hyper-V firewall, the VPN path, and routing first. A kernel investigation becomes justified when the entire distribution stops or VmmemWSL restarts and the kernel log from the same time contains panic, Oops, or Call Trace.

The goal is not to declare netvsc the cause. Build one evidence set containing the network mode, WSL, Windows, and kernel versions, the call trace, and the result of a controlled NAT comparison. That set helps decide whether to investigate ordinary connectivity, the mirrored path, or the Linux kernel and workload. This procedure cross-checks official documentation and the documented driver scope; it does not claim reproduction of a specific kernel defect on test hardware.

Symptoms and Exact Error

Observed behavior Initial classification Next check
The WSL shell is alive, but one service or port fails Ordinary networking or binding problem Listening address, Hyper-V firewall, VPN, and routing
The distribution stops or VmmemWSL restarts Possible WSL VM or kernel failure Failure time, previous-boot logs, and WSL diagnostics
The log contains only the string netvsc Cause not established The first failing frame around the panic, Oops, and call trace
Mirrored mode stops, while NAT passes the same workload Scope narrowed to the mirrored path Repeat with fixed WSL versions and collect official logs
NAT and mirrored mode stop with the same call trace Unlikely to be mode-specific Distribution kernel, modules, and network workload

netvsc is the Linux driver for Hyper-V synthetic network devices. It supports features such as checksum offload, RSS, and GRO/LRO, but a feature list cannot establish the cause of a particular panic. Read the position of the driver name together with the frames before and after it.

Values to Check First

Immediately after the failure, preserve the following Windows-side information in one file. .wslconfig is a per-user global configuration file, so a missing-file result is also useful evidence.

Collect full configuration and logs privately because they can contain user paths and identifiers. The read below assumes UTF-8; use the existing encoding if different. If the file was originally absent, rollback removes only the file created for this test, after checking for unrelated changes.

wsl --version
wsl --status
wsl -l -v
Get-Content -LiteralPath "$env:USERPROFILE\.wslconfig" -Encoding UTF8
Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber

At minimum, record the Windows build, WSL version, WSL kernel version, distribution name and state, and the networkingMode value. Microsoft documents mirrored mode for Windows 11 22H2 or later, enabled with networkingMode=mirrored under [wsl2]. If that prerequisite is not met, do not apply this mirrored-mode branch.

If the WSL shell can be opened again, collect interface and kernel evidence inside Linux.

uname -a
ip -br link
ip -s link
dmesg -T | grep -iE 'panic|oops|call trace|netvsc|hv_netvsc'

An empty search result is not evidence of a kernel panic. The next command is useful only when the distribution uses systemd, persistent journaling is enabled, and the previous boot remains available.

journalctl -k -b -1 --no-pager | grep -iE 'panic|oops|call trace|netvsc|hv_netvsc'

If the output says No journal files were found or no previous boot exists, record that this method could not retrieve the earlier log. Preserve the current state before changing journal retention.

Cause Branches: Comparing Mirrored and NAT

A network-mode comparison narrows scope; it does not prove a root cause. Keep the VPN state, requests, workload duration, and WSL and Windows versions unchanged, and change only networkingMode. Back up the configuration and save work in every running distribution first.

$wslConfig = Join-Path $env:USERPROFILE '.wslconfig'
if (Test-Path -LiteralPath $wslConfig) {
    $wslBackup = $wslConfig + '.before-network-test.' + [guid]::NewGuid().ToString('N')
    Copy-Item -LiteralPath $wslConfig -Destination $wslBackup -ErrorAction Stop
} else {
    Write-Output 'Original .wslconfig was absent; record this before creating one.'
}

Do not replace the entire .wslconfig with the two lines below. Preserve its encoding, comments, memory, processors, kernel, and experimental settings; edit only networkingMode in the existing [wsl2] section to nat. Add the key once if absent, without duplicate sections or keys. The fragment below shows only the setting to edit. After saving the file and work in every distribution, wsl --shutdown stops all WSL2 distributions and the VM.

[wsl2]
networkingMode=nat

Repeat the same request in the same order. A single successful run is weak evidence. The useful result is repeated VM termination in mirrored mode while the same workload repeatedly passes in NAT. If NAT produces the same call trace, discard the mirrored-only hypothesis.

Interpreting the A/B Result

Mirrored result NAT result Interpretation
VM stops with the same call trace repeatedly Normal Investigate the mirrored path or a combination exposed only on that path
Only a particular port fails while the VM remains alive Normal Investigate the Hyper-V firewall, VPN, and service binding first
VM stops with a repeated call trace Stops in the same way Expand the scope to the distribution kernel, modules, and workload
Both modes are normal Normal Preserve versions and conditions; do not declare a transient event permanently fixed

Microsoft’s WSL networking documentation describes mirrored mode as a separate architecture that mirrors Windows interfaces into Linux and can be affected by the Hyper-V firewall. When the VM remains alive but inbound connections fail, verify firewall policy and the application’s listening address before changing kernel options.

Fix Sequence

  1. Preserve original evidence. Save version output, .wslconfig, the call trace, and the failure time before making changes.
  2. Update WSL. Run wsl --update from PowerShell, then verify the actual value reported by wsl --version instead of relying on a success message.
  3. Restore the original mode. Restore the backed-up configuration, run wsl --shutdown, and repeat the same traffic.
  4. Collect official diagnostics if the failure remains. Follow Microsoft’s WSL log-collection procedure. Before attaching the result publicly, inspect account names, user paths, internal IP addresses, and domains.
  5. Distinguish a hang from a panic. A completely unresponsive WSL environment may require the documented VmmemWSL dump procedure. A simple connection failure does not justify starting with a memory dump.

Verification and Rollback

  • Do not label the driver defective merely because netvsc appears without a call trace.
  • Do not change firewall policy, VPN state, offload features, and network mode in one experiment. Doing so destroys the ability to attribute the result.
  • Do not disable LRO/GRO with ethtool -K without evidence specific to the failure. The Linux documentation describes general driver features, not a fix command for this panic.
  • Do not unregister the distribution or delete its virtual disk for diagnosis. This procedure requires no data deletion.
  • Do not record the NAT workaround as a permanent fix. Preserve the condition for restoring and retesting the original mode.

What the Official Documentation Supports

Microsoft’s WSL troubleshooting guide recommends separating failures among the Linux binary, distribution, WSL stack, and hardware, then collecting official logs for WSL-specific problems. The WSL networking documentation describes mirrored-mode prerequisites and the effect of the Hyper-V firewall. The Linux kernel documentation describes netvsc features such as offload, RSS, and receive buffers.

Those documents do not say that every mirrored-mode termination is a netvsc defect. This guide therefore does not present a particular patch as the answer. It narrows scope only after a call trace and a controlled comparison between network modes are available.

Official Documentation