Home networking troubleshooting windows wireless

Troubleshooting Wireless Network Connectivity Problems in Windows

Updated: • 0 • min read
Table of Contents

Troubleshooting Wireless Network Connectivity Problems in Windows

This guide focuses on troubleshooting issues when establishing Wi-Fi connections from Windows clients. Understanding the fundamental flow of the Wi-Fi autoconnect state machine is crucial. This knowledge helps in identifying the starting point for troubleshooting scenarios where unexpected behavior occurs. The techniques described here leverage detailed tracing and analysis.

Troubleshooting Wi-Fi connections can be complex due to the intricate interplay of various system components. A systematic approach, focusing on the sequence of events during a connection attempt, is highly effective. This article utilizes the TextAnalysisTool, a powerful utility for filtering and examining extensive trace logs, particularly those generated by the wireless_dbg scenario. This tool is indispensable for navigating the verbose output produced during wireless diagnostics.

Scenarios

This troubleshooting methodology is applicable to any situation where establishing a Wi-Fi connection fails in Windows. While the primary focus is on Windows 10 clients, the principles and tracing techniques can be beneficial for analyzing traces from earlier Windows versions, including Windows 7. The goal is to pinpoint the exact stage in the connection process where the failure occurs.

Wireless Event Tracing for Windows (ETW) is inherently detailed, often logging numerous events that may appear as errors but are routine behaviors unrelated to the core problem. Simply searching or filtering for terms like “err”, “error”, or “fail” in ETW logs is usually counterproductive. This approach tends to generate a large volume of irrelevant information, obscuring the true context of the Wi-Fi issue. A deeper understanding of the underlying processes is required.

It is essential to grasp the roles of the different Wi-Fi components involved in the connection process. Knowing their expected behaviors allows you to identify precisely where the problem scenario deviates from the normal flow. This guide aims to demonstrate how to find a specific starting point within the voluminous wireless_dbg ETW trace. By doing so, you can efficiently narrow down the investigation to the components responsible for the connection problem.

Known Issues and Fixes

Before diving into detailed tracing, ensure your Windows installation is up to date. Many common connectivity issues are resolved through cumulative updates and security rollups. Checking for and installing the latest patches can save significant troubleshooting time. Referencing the appropriate update history pages for your specific Windows version is recommended to confirm your system’s update status.

Below is a table summarizing known issues and the specific Windows updates that address them.

OS version Fixed in
Windows 10, version 1803 KB4284848
Windows 10, version 1709 KB4284822
Windows 10, version 1703 KB4338827

Always make sure that you install the latest Windows updates, cumulative updates, and rollup updates available for your operating system. This preventative step is often sufficient to resolve many transient or previously identified wireless connectivity problems. Microsoft provides detailed update history pages for all supported Windows versions, allowing users to verify installed updates.

Data Collection

To effectively troubleshoot wireless connectivity issues, collecting a detailed network trace is the first critical step. This involves capturing ETW events specifically related to wireless activity. The netsh trace command is used for this purpose, providing a comprehensive log of network events.

Follow these steps to collect the necessary data:

  1. Open an elevated command prompt. This requires running Command Prompt as an administrator to execute the tracing commands.
  2. Start the network trace with the wireless_dbg scenario enabled. The command below initiates the trace, enables wireless debugging, captures network packets, allows the trace file to overwrite previous captures, sets a maximum size, and specifies the output file path.
    netsh trace start wireless_dbg capture=yes overwrite=yes maxsize=4096 tracefile=c:\tmp\wireless.etl

    This command configures the tracing session. Pay attention to the output, which confirms the settings like trace file location, append mode, circular logging, and maximum size.
  3. Reproduce the issue you are troubleshooting.
    • If the failure occurs when trying to establish a connection, attempt to manually connect to the Wi-Fi network again.
    • If the issue is intermittent but happens frequently, try connecting manually several times until a failure occurs. It is helpful to note the exact time of each connection attempt and whether it succeeded or failed.
    • For intermittent but rare issues, consider automating the netsh trace stop command or setting up alerts. This ensures the trace doesn’t fill up and overwrite the critical data before the infrequent failure occurs.
    • If the problem is intermittent connection drops, write a script that constantly tests network connectivity (e.g., using ping). Trigger the netsh trace stop command automatically within the script when the test detects a network failure.
  4. Once the issue has been reproduced and captured, stop the trace using the following command in the elevated command prompt.
    netsh trace stop

    Stopping the trace triggers the correlation and merging of data. It generates a .cab file containing the trace and other system information, along with the raw .etl trace file.
  5. Convert the raw .etl output file into a human-readable text format. This step is necessary before the trace can be effectively analyzed with tools like TextAnalysisTool. Use the command below, specifying the input .etl file.
    netsh trace convert c:\tmp\wireless.etl

    This command processes the .etl file and creates a .txt file containing the trace logs in a textual format. After completing these steps, you should have three main files in your specified directory: wireless.cab, wireless.etl, and wireless.txt. The .txt file is the primary file used for analysis with TextAnalysisTool.

Troubleshooting

Analyzing the collected trace data requires understanding the major components involved in Windows Wi-Fi connectivity and their typical interactions. A high-level view helps contextualize the events seen in the trace logs. These components work together to manage scanning, connection attempts, security, and data transfer over the wireless medium.

Here is a breakdown of the key Wi-Fi components in Windows:

Wi-Fi Components Description
Windows Connection Manager (Wcmsvc) Works closely with the user interface elements, such as the taskbar network icon, to manage connections to various networks, including wireless ones. It receives user input and passes it to the core wireless services for processing.
WLAN Autoconfig Service (WlanSvc) Handles the fundamental operations of wireless networks within Windows. Its responsibilities include scanning for available wireless networks within range and managing the process of connecting to and maintaining connectivity.
Media Specific Module (MSM) Focuses on handling the security aspects involved in establishing a wireless connection. This includes managing authentication and encryption processes to ensure a secure link.
Native WiFi stack Comprises drivers and wireless APIs that facilitate interaction with wireless miniport drivers. This layer is responsible for translating wireless 802.11 frames into 802.3 Ethernet frames for use by higher-layer protocols like TCP/IP.
Third-party wireless miniport drivers Provide the interface between the operating system’s wireless stack and the actual wireless hardware. These drivers receive commands from Windows and provide notifications about hardware status and events.

The Wi-Fi connection process in Windows follows a defined state machine. Understanding these states and the transitions between them is fundamental to diagnosing connection issues. A successful connection progresses through a specific sequence of states. Failures often manifest as the state machine getting stuck in a particular state or transitioning unexpectedly.

The primary states of the Wi-Fi connection state machine include:

  • Reset
  • Ihv_Configuring
  • Configuring
  • Associating
  • Authenticating
  • Roaming
  • Wait_For_Disconnected
  • Disconnected

Standard connection and disconnection processes involve transitions between these states. A typical successful connection attempt follows a progression from Disconnected to Connected through intermediate states. Disconnecting involves transitioning from Connected back to Disconnected, potentially through Roaming and Wait_For_Disconnected.

Examining the state machine transitions is an effective initial step when analyzing the ETW trace using the TextAnalysisTool (TAT). A specific filter for “FSM transition” can isolate these key events in the trace. This quickly reveals the state the connection attempt reached before failing. Identifying the last successful state helps narrow down the scope of further investigation.

Here is an example of a successful connection setup as seen in the trace logs with the FSM transition filter applied:

44676 [2]0F24.1020::2018-09-17 10:22:14.658 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State: Disconnected to State: Reset
45473 [1]0F24.1020::2018-09-17 10:22:14.667 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State: Reset to State: Ihv_Configuring
45597 [3]0F24.1020::2018-09-17 10:22:14.708 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State: Ihv_Configuring to State: Configuring
46085 [2]0F24.17E0::2018-09-17 10:22:14.710 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State: Configuring to State: Associating
47393 [1]0F24.1020::2018-09-17 10:22:14.879 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State: Associating to State: Authenticating
49465 [2]0F24.17E0::2018-09-17 10:22:14.990 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State: Authenticating to State: Connected

In contrast, a failed connection setup would show the state machine stopping or transitioning to an unexpected state before reaching “Connected”. For example, it might transition from “Authenticating” directly to “Roaming” or “Disconnected” prematurely.

Consider this example of a failed connection setup trace:

44676 [2]0F24.1020::2018-09-17 10:22:14.658 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State: Disconnected to State: Reset
45473 [1]0F24.1020::2018-09-17 10:22:14.667 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State: Reset to State: Ihv_Configuring
45597 [3]0F24.1020::2018-09-17 10:22:14.708 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State: Ihv_Configuring to State: Configuring
46085 [2]0F24.17E0::2018-09_17 10:22:14.710 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State: Configuring to State: Associating
47393 [1]0F24.1020::2018-09-17 10:22:14.879 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State: Associating to State: Authenticating
49465 [2]0F24.17E0::2018-09-17 10:22:14.990 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State: Authenticating to State: Roaming

By identifying the state where the connection process stalled or transitioned incorrectly, you can concentrate your analysis on the trace logs immediately preceding that problematic state change. The logs from the [Microsoft-Windows-WLAN-AutoConfig] provider before the bad state transition should provide clues about the underlying issue. However, errors often originate from components lower in the stack.

The Media Specific Module (MSM) is a key component that interfaces closely with WlanSvc, particularly regarding security. When the main FSM indicates a problem, especially during or after authentication states, examining the MSM’s activity is the next logical step. The MSM manages the security handshake required for the connection.

The important components within the MSM include:

  • Security Manager (SecMgr): This handles all security operations, both before and after the connection is fully established.
  • Authentication Engine (AuthMgr): This component specifically manages 802.1X authentication requests, which are common in enterprise or secure network environments.

Each of these internal MSM components also operates through its own state machines, following defined transitions. By enabling additional filters in TextAnalysisTool for SecMgr Transition and AuthMgr Transition, you can gain more granular insight into the security aspects of the connection attempt. Combining these filters with the main FSM filter provides a comprehensive view of the connection progress at different levels.

Using multiple filters in TAT, such as FSM transition, SecMgr Transition, and AuthMgr Transition, allows you to see how these state machines progress in parallel. This can help correlate events across different components. A combined view often highlights precisely where the security handshake fails or deviates from the expected path.

Here is an example showing combined state machine transitions, which might indicate a problem during authentication:

[2] 0C34.2FF0::08/28/17-13:24:28.693 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State:
Reset to State: Ihv_Configuring
[2] 0C34.2FF0::08/28/17-13:24:28.693 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State:
Ihv_Configuring to State: Configuring
[1] 0C34.2FE8::08/28/17-13:24:28.711 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State:
Configuring to State: Associating
[0] 0C34.275C::08/28/17-13:24:28.902 [Microsoft-Windows-WLAN-AutoConfig]Port[13] Peer 8A:15:14:B6:25:10 SecMgr Transition INACTIVE (1) --> ACTIVE (2)
[0] 0C34.275C::08/28/17-13:24:28.902 [Microsoft-Windows-WLAN-AutoConfig]Port[13] Peer 8A:15:14:B6:25:10 SecMgr Transition ACTIVE (2) --> START AUTH (3)
[4] 0EF8.0708::08/28/17-13:24:28.928 [Microsoft-Windows-WLAN-AutoConfig]Port (14) Peer 0x186472F64FD2 AuthMgr Transition ENABLED --> START_AUTH
[3] 0C34.2FE8::08/28/17-13:24:28.902 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State:
Associating to State: Authenticating
[1] 0C34.275C::08/28/17-13:24:28.960 [Microsoft-Windows-WLAN-AutoConfig]Port[13] Peer 8A:15:14:B6:25:10 SecMgr Transition START AUTH (3) --> WAIT FOR AUTH SUCCESS (4)
[4] 0EF8.0708::08/28/17-13:24:28.962 [Microsoft-Windows-WLAN-AutoConfig]Port (14) Peer 0x186472F64FD2 AuthMgr Transition START_AUTH --> AUTHENTICATING
[2] 0C34.2FF0::08/28/17-13:24:29.751 [Microsoft-Windows-WLAN-AutoConfig]Port[13] Peer 8A:15:14:B6:25:10 SecMgr Transition WAIT FOR AUTH SUCCESS (7) --> DEACTIVATE (11)
[2] 0C34.2FF0::08/28/17-13:24:29.7512788 [Microsoft-Windows-WLAN-AutoConfig]Port[13] Peer 8A:15:14:B6:25:10 SecMgr Transition DEACTIVATE (11) --> INACTIVE (1)
[2] 0C34.2FF0::08/28/17-13:24:29.7513404 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State:
Authenticating to State: Roaming

In this combined view, the state machine transitions (FSM, SecMgr, AuthMgr) are shown together. The sequence progresses through association and begins authentication. However, the SecMgr transitions from WAIT FOR AUTH SUCCESS to DEACTIVATE, and AuthMgr doesn’t complete. Subsequently, the main FSM transitions to Roaming instead of Connected, indicating an authentication failure. To understand why this happened, you need to look at the specific logs from [Microsoft-Windows-WLAN-AutoConfig] around the time of the transition to DEACTIVATE.

Enabling the broader [Microsoft-Windows-WLAN-AutoConfig] filter around the time of the failed transition provides more detailed events. This allows you to see the messages that led the SecMgr or AuthMgr state machines to deactivate or transition to a failure state. Look for events indicating problems with security packet exchange or port status changes.

Expanding the view around the failure point might reveal messages like the following, explaining the reason for deactivation:

[3] 0C34.2FE8::08/28/17-13:24:28.902 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State:
Associating to State: Authenticating
[1] 0C34.275C::08/28/17-13:24:28.960 [Microsoft-Windows-WLAN-AutoConfig]Port[13] Peer 8A:15:14:B6:25:10 SecMgr Transition START AUTH (3) --> WAIT FOR AUTH SUCCESS (4)
[4] 0EF8.0708::08/28/17-13:24:28.962 [Microsoft-Windows-WLAN-AutoConfig]Port (14) Peer 0x186472F64FD2 AuthMgr Transition START_AUTH --> AUTHENTICATING
[0]0EF8.2EF4::08/28/17-13:24:29.549 [Microsoft-Windows-WLAN-AutoConfig]Received Security Packet: PHY_STATE_CHANGE
[0]0EF8.2EF4::08/28/17-13:24:29.549 [Microsoft-Windows-WLAN-AutoConfig]Change radio state for interface = Intel(R) Centrino(R) Ultimate-N 6300 AGN : PHY = 3, software state = on , hardware state = off )
[0] 0EF8.1174::08/28/17-13:24:29.705 [Microsoft-Windows-WLAN-AutoConfig]Received Security Packet: PORT_DOWN
[0] 0EF8.1174::08/28/17-13:24:29.705 [Microsoft-Windows-WLAN-AutoConfig]FSM Current state Authenticating , event Upcall_Port_Down
[0] 0EF8.1174:: 08/28/17-13:24:29.705 [Microsoft-Windows-WLAN-AutoConfig]Received IHV PORT DOWN, peer 0x186472F64FD2
[2] 0C34.2FF0::08/28/17-13:24:29.751 [Microsoft-Windows-WLAN-AutoConfig]Port[13] Peer 8A:15:14:B6:25:10 SecMgr Transition WAIT FOR AUTH SUCCESS (7) --> DEACTIVATE (11)
[2] 0C34.2FF0::08/28/17-13:24:29.7512788 [Microsoft-Windows-WLAN-AutoConfig]Port[13] Peer 8A:15:14:B6:25:10 SecMgr Transition DEACTIVATE (11) --> INACTIVE (1)
[2] 0C34.2FF0::08/28/17-13:24:29.7513404 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State:
Authenticating to State: Roaming

In this more detailed trace snippet, the line [0] 0EF8.1174:: 08/28/17-13:24:29.705 [Microsoft-Windows-WLAN-AutoConfig]Received IHV PORT DOWN, peer 0x186472F64FD2 is particularly informative. A “PORT_DOWN” notification indicates that the lower layers, closer to the actual wireless hardware, have brought the connection port down. This event directly precedes the SecMgr deactivation and the main FSM transitioning to Roaming, suggesting the root cause lies below the WlanSvc and MSM layers. The trail of investigation now points towards the Native WiFi stack and the miniport driver.

The Native WiFi stack (logged by [Microsoft-Windows-NWiFi]) is the layer responsible for interacting with the wireless miniport drivers. It handles the translation of network packets between the 802.11 wireless format and the 802.3 Ethernet format used by the operating system’s networking stack (like TCP/IP). Events from this provider can indicate issues happening at the driver level or communications with the Access Point (AP).

Filtering the trace with the [Microsoft-Windows-NWiFi] provider enabled allows you to see events related to the native Wi-Fi stack’s operations. Look for messages indicating disassociations, deauthentications, or other link-layer control frames. These events often directly precede or explain the PORT_DOWN notifications seen at higher levels.

Adding the [Microsoft-Windows-NWiFi] filter to the previous view around the time of the PORT_DOWN event yields more details:

[3] 0C34.2FE8::08/28/17-13:24:28.902 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State:
Associating to State: Authenticating
[1] 0C34.275C::08/28/17-13:24:28.960 [Microsoft-Windows-WLAN-AutoConfig]Port[13] Peer 8A:15:14:B6:25:10 SecMgr Transition START AUTH (3) --> WAIT FOR AUTH SUCCESS (4)
[4] 0EF8.0708::08/28/17-13:24:28.962 [Microsoft-Windows-WLAN-AutoConfig]Port (14) Peer 0x8A1514B62510 AuthMgr Transition START_AUTH --> AUTHENTICATING
[0]0000.0000::08/28/17-13:24:29.127 [Microsoft-Windows-NWiFi]DisAssoc: 0x8A1514B62510 Reason: 0x4
[0]0EF8.2EF4::08/28/17-13:24:29.549 [Microsoft-Windows-WLAN-AutoConfig]Received Security Packet: PHY_STATE_CHANGE
[0]0EF8.2EF4::08/28/17-13:24:29.549 [Microsoft-Windows-WLAN-AutoConfig]Change radio state for interface = Intel(R) Centrino(R) Ultimate-N 6300 AGN : PHY = 3, software state = on , hardware state = off )
[0] 0EF8.1174::08/28/17-13:24:29.705 [Microsoft-Windows-WLAN-AutoConfig]Received Security Packet: PORT_DOWN
[0] 0EF8.1174::08/28/17-13:24:29.705 [Microsoft-Windows-WLAN-AutoConfig]FSM Current state Authenticating , event Upcall_Port_Down
[0] 0EF8.1174:: 08/28/17-13:24:29.705 [Microsoft-Windows-WLAN-AutoConfig]Received IHV PORT DOWN, peer 0x186472F64FD2
[2] 0C34.2FF0::08/28/17-13:24:29.751 [Microsoft-Windows-WLAN-AutoConfig]Port[13] Peer 8A:15:14:B6:25:10 SecMgr Transition WAIT FOR AUTH SUCCESS (7) --> DEACTIVATE (11)
[2] 0C34.2FF0::08/28/17-13:24:29.7512788 [Microsoft-Windows-WLAN-AutoConfig]Port[13] Peer 8A:15:14:B6:25:10 SecMgr Transition DEACTIVATE (11) --> INACTIVE (1)
[2] 0C34.2FF0::08/28/17-13:24:29.7513404 [Microsoft-Windows-WLAN-AutoConfig]FSM Transition from State:
Authenticating to State: Roaming

In this enhanced trace output, a crucial line appears before the PHY_STATE_CHANGE and PORT_DOWN events: [0]0000.0000::08/28/17-13:24:29.127 [Microsoft-Windows-NWiFi]DisAssoc: 0x8A1514B62510 Reason: 0x4. This log indicates a Disassociation frame was received from the Access Point (AP) with the MAC address 8A:15:14:B6:25:10, specifying reason code 0x4. Reason code 4 typically means “Disassociated due to inactivity” or “Disassociated because the STA is leaving”. However, the specific reason code interpretation depends on the 802.11 standard and vendor implementation.

Receiving a Disassociation frame from the AP is a direct instruction to terminate the wireless connection. This is the likely cause of the subsequent PHY_STATE_CHANGE and PORT_DOWN events reported by higher layers. The root cause of the client’s connection failure, in this specific trace example, appears to be the AP actively terminating the connection. To fully diagnose this issue, the next step would involve examining logs or traces from the Access Point itself to understand why it sent the Disassociation frame with that specific reason code. Potential reasons could include incorrect credentials (though typically handled during authentication), connection parameter mismatches, or other AP-side policies or events.

More information on related topics can be found by researching 802.11 Wireless Tools and Settings and understanding 802.1X authentication for wireless networks. These topics provide deeper context on the standards and protocols involved in the Wi-Fi connection process.

Example ETW Capture

The following console output shows the process of starting and stopping a netsh trace session and then converting the output file. This demonstrates the commands and the expected feedback from the system. The resulting files are essential for the troubleshooting process described above.

C:\tmp>netsh trace start wireless_dbg capture=yes overwrite=yes maxsize=4096 tracefile=c:\tmp\wireless.etl

Trace configuration:
-------------------------------------------------------------------
Status:             Running
Trace File:         C:\tmp\wireless.etl
Append:             Off
Circular:           On
Max Size:           4096 MB
Report:             Off

C:\tmp>netsh trace stop
Correlating traces ... done
Merging traces ... done
Generating data collection ... done
The trace file and additional troubleshooting information have been compiled as "c:\tmp\wireless.cab".
File location = c:\tmp\wireless.etl
Tracing session was successfully stopped.

C:\tmp>netsh trace convert c:\tmp\wireless.etl

Input file:  c:\tmp\wireless.etl
Dump file:   c:\tmp\wireless.txt
Dump format: TXT
Report file: -
Generating dump ... done

C:\tmp>dir
 Volume in drive C has no label.
 Volume Serial Number is 58A8-7DE5

 Directory of C:\tmp

01/09/2019  02:59 PM    [DIR]          .
01/09/2019  02:59 PM    [DIR]          ..
01/09/2019  02:59 PM         4,855,952 wireless.cab
01/09/2019  02:56 PM         2,752,512 wireless.etl
01/09/2019  02:59 PM         2,786,540 wireless.txt
               3 File(s)     10,395,004 bytes
               2 Dir(s)  46,648,332,288 bytes free

This output confirms that the trace was started, stopped, and successfully converted. The wireless.txt file is now ready for analysis using the TextAnalysisTool. The .cab file can be useful if additional system information is needed, but the text file contains the detailed ETW logs.

Wifi Filter File

The TextAnalysisTool (TAT) allows the use of filter files to quickly apply complex filtering rules to large text logs. The following XML content represents a useful filter configuration for analyzing wireless traces. This filter set is designed to exclude noisy or irrelevant providers while highlighting key events and state transitions from the important Wi-Fi components like WLAN-AutoConfig, NWiFi, SecMgr, and AuthMgr.

To use this filter, copy the entire XML block below and paste it into a plain text file. Save this file with a .tat extension (e.g., wifi.tat). Then, within the TextAnalysisTool application, load your wireless.txt trace file and apply this filter file by navigating to the File menu and selecting Load Filters. This will apply the defined rules, making the trace analysis much more focused and manageable.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<TextAnalysisTool.NET version="2018-01-03" showOnlyFilteredLines="False">
  <filters>
    <filter enabled="n" excluding="n" description="" foreColor="000000" backColor="d3d3d3" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-OneX]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Unknown]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-EapHost]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[]***" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-Winsock-AFD]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-WinHttp]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-WebIO]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-Winsock-NameResolution]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-TCPIP]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-DNS-Client]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-NlaSvc]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-Iphlpsvc-Trace]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-DHCPv6-Client]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-Dhcp-Client]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-NCSI]" />
    <filter enabled="y" excluding="n" description="" backColor="90ee90" type="matches_text" case_sensitive="n" regex="n" text="AuthMgr Transition" />
    <filter enabled="y" excluding="n" description="" foreColor="0000ff" backColor="add8e6" type="matches_text" case_sensitive="n" regex="n" text="FSM transition" />
    <filter enabled="y" excluding="n" description="" foreColor="000000" backColor="dda0dd" type="matches_text" case_sensitive="n" regex="n" text="SecMgr transition" />
    <filter enabled="y" excluding="n" description="" foreColor="000000" backColor="f08080" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-NWiFi]" />
    <filter enabled="y" excluding="n" description="" foreColor="000000" backColor="ffb6c1" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-WiFiNetworkManager]" />
    <filter enabled="y" excluding="n" description="" foreColor="000000" backColor="dda0dd" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-WLAN-AutoConfig]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-NetworkProfile]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-WFP]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[Microsoft-Windows-WinINet]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="[MSNT_SystemTrace]" />
    <filter enabled="y" excluding="y" description="" foreColor="000000" backColor="ffffff" type="matches_text" case_sensitive="n" regex="n" text="Security]Capability" />
  </filters>
</TextAnalysisTool.NET>

This filter file is configured to exclude many common, but often irrelevant, network trace providers by default. It includes and highlights (potentially with background colors, depending on the tool’s rendering) the key providers and transition messages that are most valuable when troubleshooting Wi-Fi connection state issues. Filters for FSM transition, SecMgr transition, AuthMgr Transition, [Microsoft-Windows-WLAN-AutoConfig], and [Microsoft-Windows-NWiFi] are enabled to help you follow the connection logic.

TextAnalysisTool example

TextAnalysisTool provides a graphical interface to load and filter the trace text file (wireless.txt). By loading the wifi.tat filter file, the tool will apply the specified rules, making it easier to scan through the large volume of logs. The filters highlight or hide lines based on their content, allowing you to quickly locate the state transitions and key events discussed in the troubleshooting section.

For instance, applying the FSM transition filter would show only the lines indicating changes in the main Wi-Fi connection state machine, similar to the examples provided earlier. Enabling multiple transition filters simultaneously allows you to see the coordinated (or uncoordinated) movement through the FSM, SecMgr, and AuthMgr states. Using the specific provider filters like [Microsoft-Windows-WLAN-AutoConfig] or [Microsoft-Windows-NWiFi] lets you drill down into the detailed logs from those components when the state transitions indicate a potential issue in that layer. This methodical approach, guided by the state machine flow, is the most efficient way to pinpoint the root cause of wireless connectivity problems using ETW traces.

Troubleshooting wireless network connectivity issues can be challenging, but by collecting detailed traces and using analysis tools like TextAnalysisTool with appropriate filters, you can gain the visibility needed to diagnose problems effectively. Understanding the state machines and component interactions provides a roadmap through the complexities of the logs.

Have you used ETW tracing or TextAnalysisTool to diagnose network issues before? Share your experiences or ask questions about using these techniques in the comments below.

Post a Comment