Windows 11 Dropping Wi-Fi on Boot? Blame Your VPN Kill Switch

Windows 11 Dropping Wi-Fi on Boot? Blame Your VPN Kill Switch

# networking# security# todayilearned# tutorial
Windows 11 Dropping Wi-Fi on Boot? Blame Your VPN Kill SwitchDavid Timothy

Every developer has a familiar morning ritual: power on the workstation, grab a fresh cup of coffee,...

Every developer has a familiar morning ritual: power on the workstation, grab a fresh cup of coffee, fire up the terminal, and wait for local containers and background daemons to spin up.

Except lately, Windows 11 has been injecting an infuriating obstacle into that workflow: roughly five to ten seconds after reaching the desktop, your Wi-Fi silently disconnects. You open the network tray, hit connect manually, and it reconnects immediately without missing a beat for the rest of the workday. Reboot tomorrow, however, and the cycle repeats.

If you run an always-on VPN with a persistent, strict kill switch (such as Mullvad's Lockdown mode, IVPN's Always-On Firewall, or a locked-down WireGuard interface), this is not hardware degradation, access-point instability, or a corrupt Wi-Fi driver.

It is a silent race condition between Windows 11's network connection heuristics and your VPN's low-level packet filter. Here is what is happening under the hood, how to inspect the diagnostic traces in Event Viewer, and the one-line registry fix that permanently resolves it.

The Three Components in Conflict

To understand why the wireless link drops, we need to inspect three distinct Windows networking components that boot simultaneously:

1. The VPN Kill Switch and Windows Filtering Platform (WFP)

Modern privacy-focused VPN clients do not wait for a user GUI to launch before establishing protection. They install persistent filters directly into the Windows Filtering Platform (WFP) at the kernel level.

When you enable a "Hard Kill Switch" or "Lockdown Mode", these WFP callout drivers enforce a strict rule right from machine initialization: block all outbound and inbound IP packets unless they route through the virtual TUN/TAP adapter or target the specific IP/port of the upstream VPN gateway.

2. Network Connectivity Status Indicator (NCSI)

As soon as an adapter comes online, the NCSI engine tries to answer a basic question: Does this interface actually reach the public internet?

To verify reachability, NCSI executes active probes:

  • A DNS request to resolve Microsoft test hosts (such as dns.msftncsi.com).
  • An active HTTP probe requesting a specific text string (traditionally http://www.msftconnecttest.com/connecttest.txt).

If the probe returns the expected text, Windows displays the standard "Internet access" globe. If it times out or returns unexpected content, Windows tags the interface with "No internet access" or "Limited connectivity".

3. Windows Connection Manager (WcmSvc) and Bad State Tracking

The Windows Connection Manager service (WcmSvc) monitors available network interfaces (Wi-Fi, Ethernet, WWAN) and decides which connection the operating system should prioritize.

To help casual users avoid stuck states on degraded Wi-Fi networks, Microsoft introduced an aggressive health evaluation feature known as Bad State Tracking. When a Wi-Fi connection is associated with a router but fails to complete NCSI reachability probes, WcmSvc treats the interface as defective or dead.

The Boot-Time Race Condition

Here is how those three components trip over each other during the first ten seconds of booting:

sequenceDiagram
    autonumber
    participant AP as Wi-Fi Access Point
    participant NIC as Wi-Fi Adapter (WlanSvc)
    participant WCM as Connection Manager (WcmSvc)
    participant WFP as VPN Kill Switch (WFP)
    participant VPN as VPN Tunnel Daemon

    NIC->>AP: L2/L3 Association & DHCP complete
    WFP->>WFP: Boot-time kill switch active (Drop all non-VPN traffic)
    NIC->>WCM: Link UP (Local IP assigned)
    WCM->>WCM: NCSI fires HTTP probe to msftconnecttest.com
    WCM--xWFP: Probe BLOCKED by firewall (Tunnel not ready yet)
    Note over WCM: NCSI probe failed -> State: "Limited Connectivity"
    Note over WCM: Bad State Tracking triggers: "Interface is degraded"
    WCM->>NIC: Force Disconnect / Reset Wi-Fi Association
    VPN->>NIC: Cannot reach VPN Gateway (Physical link severed)
    Note over VPN: Connection loop: Physical link dead, VPN blocked
  1. Physical Link Ready: Your Wi-Fi adapter associates with your access point, completes WPA authentication, and receives a local IP address via DHCP.
  2. Firewall Active: The VPN service initiates, immediately enforcing boot-time WFP rules.
  3. The Race Begins: The VPN client begins handshaking with its remote gateway (sending WireGuard or OpenVPN auth packets). Simultaneously, Windows fires NCSI active probes.
  4. The Block: Because the secure tunnel is still in mid-handshake, any raw, unencrypted HTTP probes sent by Windows outside the tunnel are instantly dropped by the WFP kill switch.
  5. The Drop: WcmSvc evaluates the failed probes, concludes that the Wi-Fi link is unusable, and orders the WLAN stack (WlanSvc) to terminate the wireless association in an attempt to trigger an automatic network recovery.
  6. The Result: The Wi-Fi adapter disconnects from your router. Because the underlying physical route vanished, the VPN handshake aborts, leaving you completely offline until you manually click "Connect" again.

Checking the Event Viewer Evidence

If you want to verify that this exact mechanism is causing your drops, you do not need third-party tools. The diagnostic trail is recorded in the Windows Event Log:

  1. Press Win + R, type eventvwr.msc, and press Enter.
  2. Navigate to: Applications and Services Logs > Microsoft > Windows > WLAN-AutoConfig > Operational
  3. Look for warning events with IDs corresponding to network recovery right around your boot timestamp:
    • Event ID 11000 / 11004: WLAN AutoConfig detected limited connectivity, attempting automatic recovery.
    • You will often see details such as: Recovery Type: 4, Trigger Reason: 5.

When correlated with the NCSI/Operational log showing ActiveHttpProbeFailed, the diagnosis is clear: Windows is intentionally dropping a healthy local Wi-Fi connection because it cannot distinguish between a broken router and a firewall intentionally blocking test packets.

The Fix: Disabling EnableBadStateTracking

To stop Windows from unilaterally severing your Wi-Fi connection, you can instruct WcmSvc to disable its bad state disconnect behavior through the Windows Registry.

Step 1: Open an Elevated Command Prompt

Click the Start menu, type cmd, right-click Command Prompt, and select Run as administrator.

Step 2: Add the Registry Value

Paste and execute the following command:

reg add "HKLM\SOFTWARE\Microsoft\WcmSvc" /v EnableBadStateTracking /t REG_DWORD /d 0 /f
Enter fullscreen mode Exit fullscreen mode

For PowerShell users running as Administrator:

New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\WcmSvc" -Name "EnableBadStateTracking" -Value 0 -PropertyType DWORD -Force
Enter fullscreen mode Exit fullscreen mode

What this parameter breakdown means:

  • HKLM\SOFTWARE\Microsoft\WcmSvc: Points to the configuration tree of the Windows Connection Manager service.
  • /v EnableBadStateTracking: Defines the registry value name responsible for tracking and acting on degraded network states.
  • /t REG_DWORD: Sets the data type to a standard 32-bit unsigned integer.
  • /d 0: Assigns a value of 0 (Disabled).
  • /f: Overwrites any existing entry without prompting for confirmation.

Step 3: Reboot

Restart your PC. Because WcmSvc is a core service loaded early in the Windows architecture, a complete reboot is required for the new configuration to take effect.

Security & Operational Analysis

Whenever you modify system-level networking parameters, it is reasonable to question the security implications.

Does this weaken your VPN Kill Switch?

No.

It is vital to distinguish between data plane security and link layer management:

  • WcmSvc only controls interface associations (whether your Wi-Fi card stays connected to the local router).
  • The VPN kill switch lives in the Windows Filtering Platform (WFP), inspecting, permitting, or dropping individual packets at layers 3 and 4.

Setting EnableBadStateTracking to 0 does not open ports, alter route tables, bypass DNS leak protections, or weaken firewall policies. If the VPN tunnel drops unexpectedly, the WFP filters still block every non-VPN packet from leaving your machine.

What are the actual trade-offs?

The only side effect is behavioral: if you connect to a genuinely broken Wi-Fi network (for example, a hotel router that has lost its upstream fiber connection), Windows will no longer automatically drop the Wi-Fi connection in an attempt to cycle adapters. It will stay associated with the local router and simply show the "No Internet" status icon in your system tray. For development machines and controlled home/office setups, this is typically the preferred behavior.

How to Roll Back

If you ever wish to revert this setting back to stock Windows behavior, run this single command from an elevated prompt:

reg delete "HKLM\SOFTWARE\Microsoft\WcmSvc" /v EnableBadStateTracking /f
Enter fullscreen mode Exit fullscreen mode

Restart your computer, and Windows Connection Manager will resume its default recovery routines.

Final Thoughts

Modern operating systems try aggressively to automate network diagnostics for general consumers. However, when you introduce privacy tools, custom WireGuard profiles, or zero-trust endpoint agents, these automated "self-healing" heuristics often turn into breaking race conditions.

By disabling bad state tracking, you stop Windows from second-guessing your network topology, allowing your local Wi-Fi link to remain steady while your VPN tunnel initializes cleanly.

References & Further Reading