diff --git a/windows/client-management/advanced-troubleshooting-wireless-network-connectivity.md b/windows/client-management/advanced-troubleshooting-wireless-network-connectivity.md
index 0354d8e90c..c773ad40ec 100644
--- a/windows/client-management/advanced-troubleshooting-wireless-network-connectivity.md
+++ b/windows/client-management/advanced-troubleshooting-wireless-network-connectivity.md
@@ -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:
-
+```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
-
+```
The following is an example of a failed connection setup:
-
+```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
-
+```
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:
-
+```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
-
+```
> [!NOTE]
> In the next to last line the SecMgr transition is suddenly deactivating:
@@ -182,7 +182,7 @@ Authenticating to State: Roaming
Enabling the **Microsoft-Windows-WLAN-AutoConfig** filter will show more detail leading to the DEACTIVATE transition:
-
+```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
-
+```
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]:**
-
+```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
+Authenticating to State: Roaming
+```
In the trace above, we see the line:
-
-[0]0000.0000::08/28/17-13:24:29.127 [Microsoft-Windows-NWiFi]DisAssoc: 0x8A1514B62510 Reason: 0x4
+```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
-
+```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
-
+```
## Wifi filter file
diff --git a/windows/client-management/troubleshoot-tcpip-rpc-errors.md b/windows/client-management/troubleshoot-tcpip-rpc-errors.md
index 7185b6660f..6601c0c57d 100644
--- a/windows/client-management/troubleshoot-tcpip-rpc-errors.md
+++ b/windows/client-management/troubleshoot-tcpip-rpc-errors.md
@@ -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 -e 135
```
This would give you a lot of output to look for, but you should be looking for *ip_tcp- 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
```
diff --git a/windows/client-management/troubleshoot-windows-freeze.md b/windows/client-management/troubleshoot-windows-freeze.md
index 73e66f7e52..9d73bacae3 100644
--- a/windows/client-management/troubleshoot-windows-freeze.md
+++ b/windows/client-management/troubleshoot-windows-freeze.md
@@ -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
```
diff --git a/windows/configuration/start-layout-troubleshoot.md b/windows/configuration/start-layout-troubleshoot.md
index b6a8fb09d3..68c2141629 100644
--- a/windows/configuration/start-layout-troubleshoot.md
+++ b/windows/configuration/start-layout-troubleshoot.md
@@ -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
```