mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-16 02:43:43 +00:00
Correct or add labels to code blocks
This commit is contained in:
Gary Moore
@ -60,7 +60,7 @@ Make sure that you install the latest Windows updates, cumulative updates, and r
|
||||
|
||||
1. Network Capture with ETW. Enter the following at an elevated command prompt:
|
||||
|
||||
```cmd
|
||||
```console
|
||||
netsh trace start wireless_dbg capture=yes overwrite=yes maxsize=4096 tracefile=c:\tmp\wireless.etl
|
||||
```
|
||||
2. Reproduce the issue.
|
||||
@ -70,12 +70,12 @@ Make sure that you install the latest Windows updates, cumulative updates, and r
|
||||
- If intermittent connection drops trigger stop command on a script (ping or test network constantly until fail, then netsh trace stop).
|
||||
3. Stop the trace by entering the following command:
|
||||
|
||||
```cmd
|
||||
```console
|
||||
netsh trace stop
|
||||
```
|
||||
4. To convert the output file to text format:
|
||||
|
||||
```cmd
|
||||
```console
|
||||
netsh trace convert c:\tmp\wireless.etl
|
||||
```
|
||||
|
||||
@ -119,25 +119,25 @@ Use the **FSM transition** trace filter to see the connection state machine. You
|
||||
|
||||
The following is an example of a good connection setup:
|
||||
|
||||
<pre>
|
||||
```console
|
||||
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
|
||||
</pre>
|
||||
```
|
||||
|
||||
The following is an example of a failed connection setup:
|
||||
|
||||
<pre>
|
||||
```console
|
||||
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
|
||||
</pre>
|
||||
```
|
||||
|
||||
By identifying the state at which the connection fails, one can focus more specifically in the trace on logs just prior to the last known good state.
|
||||
|
||||
@ -155,7 +155,7 @@ Enable the **FSM transition, SecMgr Transition,** and **AuthMgr Transition** fil
|
||||
|
||||
Continuing with the example above, the combined filters look like this:
|
||||
|
||||
<pre>
|
||||
```console
|
||||
[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:
|
||||
@ -173,7 +173,7 @@ Associating to State: Authenticating
|
||||
[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
|
||||
</pre>
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> In the next to last line the SecMgr transition is suddenly deactivating:<br>
|
||||
@ -182,7 +182,7 @@ Authenticating to State: Roaming
|
||||
|
||||
Enabling the **Microsoft-Windows-WLAN-AutoConfig** filter will show more detail leading to the DEACTIVATE transition:
|
||||
|
||||
<pre>
|
||||
```console
|
||||
[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)
|
||||
@ -196,7 +196,7 @@ Associating to State: Authenticating
|
||||
[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
|
||||
</pre>
|
||||
```
|
||||
|
||||
The trail backwards reveals a **Port Down** notification:
|
||||
|
||||
@ -208,7 +208,7 @@ Below, the MSM is the native wifi stack. These are Windows native wifi drivers w
|
||||
|
||||
Enable trace filter for **[Microsoft-Windows-NWifi]:**
|
||||
|
||||
<pre>
|
||||
```console
|
||||
[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)
|
||||
@ -222,12 +222,14 @@ Associating to State: 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</pre>
|
||||
Authenticating to State: Roaming
|
||||
```
|
||||
|
||||
In the trace above, we see the line:
|
||||
|
||||
<pre>
|
||||
[0]0000.0000::08/28/17-13:24:29.127 [Microsoft-Windows-NWiFi]DisAssoc: 0x8A1514B62510 Reason: 0x4</pre>
|
||||
```console
|
||||
[0]0000.0000::08/28/17-13:24:29.127 [Microsoft-Windows-NWiFi]DisAssoc: 0x8A1514B62510 Reason: 0x4
|
||||
```
|
||||
|
||||
This is followed by **PHY_STATE_CHANGE** and **PORT_DOWN** events due to a disassociate coming from the Access Point (AP), as an indication to deny the connection. This could be due to invalid credentials, connection parameters, loss of signal/roaming, and various other reasons for aborting a connection. The action here would be to examine the reason for the disassociate sent from the indicated AP MAC (8A:15:14:B6:25:10). This would be done by examining internal logging/tracing from the AP.
|
||||
|
||||
@ -238,7 +240,7 @@ This is followed by **PHY_STATE_CHANGE** and **PORT_DOWN** events due to a disas
|
||||
|
||||
## Example ETW capture
|
||||
|
||||
<pre>
|
||||
```console
|
||||
C:\tmp>netsh trace start wireless_dbg capture=yes overwrite=yes maxsize=4096 tracefile=c:\tmp\wireless.etl
|
||||
|
||||
Trace configuration:
|
||||
@ -279,7 +281,7 @@ C:\tmp>dir
|
||||
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
|
||||
</pre>
|
||||
```
|
||||
|
||||
## Wifi filter file
|
||||
|
||||
|
||||
@ -110,13 +110,13 @@ If you would like to do a deep dive as to how it works, see [RPC over IT/Pro](ht
|
||||
|
||||
The best thing to always troubleshoot RPC issues before even getting in to traces is by making use of tools like **PortQry**. You can quickly determine if you are able to make a connection by running the command:
|
||||
|
||||
```cmd
|
||||
```console
|
||||
Portqry.exe -n <ServerIP> -e 135
|
||||
```
|
||||
|
||||
This would give you a lot of output to look for, but you should be looking for <em>*ip_tcp</em>- and the port number in the brackets, which tells whether you were successfully able to get a dynamic port from EPM and also make a connection to it. If the above fails, you can typically start collecting simultaneous network traces. Something like this from the output of “PortQry”:
|
||||
|
||||
```cmd
|
||||
```console
|
||||
Portqry.exe -n 169.254.0.2 -e 135
|
||||
```
|
||||
Partial output below:
|
||||
@ -141,17 +141,20 @@ The one in bold is the ephemeral port number that you made a connection to succe
|
||||
You can run the commands below to leverage Windows inbuilt netsh captures, to collect a simultaneous trace. Remember to execute the below on an “Admin CMD”, it requires elevation.
|
||||
|
||||
- On the client
|
||||
```cmd
|
||||
|
||||
```console
|
||||
Netsh trace start scenario=netconnection capture=yes tracefile=c:\client_nettrace.etl maxsize=512 overwrite=yes report=yes
|
||||
```
|
||||
|
||||
- On the Server
|
||||
```cmd
|
||||
|
||||
```console
|
||||
Netsh trace start scenario=netconnection capture=yes tracefile=c:\server_nettrace.etl maxsize=512 overwrite=yes report=yes
|
||||
```
|
||||
|
||||
Now try to reproduce your issue from the client machine and as soon as you feel the issue has been reproduced, go ahead and stop the traces using the command
|
||||
```cmd
|
||||
|
||||
```console
|
||||
Netsh trace stop
|
||||
```
|
||||
|
||||
|
||||
@ -158,17 +158,17 @@ Learn how to use Dumpchk.exe to check your dump files:
|
||||
|
||||
You can use Windows Performance Monitor to examine how programs that you run affect your computer's performance, both in real time and by collecting log data for later analysis. To create performance counter and event trace log collections on local and remote systems, run the following commands in a command prompt as administrator:
|
||||
|
||||
```cmd
|
||||
```console
|
||||
Logman create counter LOGNAME_Long -u DOMAIN\USERNAME * -f bincirc -v mmddhhmm -max 500 -c "\\COMPUTERNAME\LogicalDisk(*)\*" "\\COMPUTERNAME\Memory\*" "\\COMPUTERNAME\Network Interface(*)\*" "\\COMPUTERNAME\Paging File(*)\*" "\\COMPUTERNAME\PhysicalDisk(*)\*" "\\COMPUTERNAME\Process(*)\*" "\\COMPUTERNAME\Redirector\*" "\\COMPUTERNAME\Server\*" "\\COMPUTERNAME\System\*" "\\COMPUTERNAME\Terminal Services\*" "\\COMPUTERNAME\Processor(*)\*" "\\COMPUTERNAME\Cache\*" -si 00:05:00
|
||||
```
|
||||
|
||||
```cmd
|
||||
```console
|
||||
Logman create counter LOGNAME_Short -u DOMAIN\USERNAME * -f bincirc -v mmddhhmm -max 500 -c "\\COMPUTERNAME\LogicalDisk(*)\*" "\\COMPUTERNAME\Memory\*" "\\COMPUTERNAME\Network Interface(*)\*" "\\COMPUTERNAME\Paging File(*)\*" "\\COMPUTERNAME\PhysicalDisk(*)\*" "\\COMPUTERNAME\Process(*)\*" "\\COMPUTERNAME\Redirector\*" "\\COMPUTERNAME\Server\*" "\\COMPUTERNAME\System\*" "\\COMPUTERNAME\Terminal Services\*" "\\COMPUTERNAME\Processor(*)\*" "\\COMPUTERNAME\Cache\*" -si 00:00:10
|
||||
```
|
||||
|
||||
Then, you can start or stop the log by running the following commands:
|
||||
|
||||
```cmd
|
||||
```console
|
||||
logman start LOGNAME_Long / LOGNAME_Short
|
||||
logman stop LOGNAME_Long / LOGNAME_Short
|
||||
```
|
||||
|
||||
@ -295,7 +295,7 @@ Additionally, users may see blank tiles if sign-in was attempted without network
|
||||
|
||||
- Open a command prompt, and run the following command:
|
||||
|
||||
```
|
||||
```console
|
||||
C:\Windows\System32\tdlrecover.exe -reregister -resetlayout -resetcache
|
||||
```
|
||||
|
||||
|
||||
Reference in New Issue
Block a user