Tracing network activity on Windows RT
Network Monitoring software such as Microsoft Network Monitor, WireShark etc are well known troubleshooting tools to collect and analyze what is being sent/ received over the Network. Fiddler is yet another useful utility to monitor HTTP requests and response. These tools work very well on the traditional Windows operating system with the x86 or x64 architecture.
However, with Windows 8.0 as well as Windows 8.1, Windows is also available on a newer processor architecture called ARM. Most of the network monitoring software that is available in the market is designed to work/run as traditional desktop software which will not run on Windows RT operating system.
This begs the question, how do you collect and analyze Network activity on Windows RT machines if you cannot use traditional desktop software to do the same?
If you aren’t already aware, there is an in-built command line utility built-into Windows called: netsh.exe which is present in C:\Windows\system32\ directory. While netsh.exe has other uses as well, this blog will only talk about the tracing functionality that netsh has to offer.
To see a complete list of what netsh has to offer, you can simply open a regular command prompt (cmd.exe) and type: netsh help.
For getting ‘help’ with the tracing functionality of netsh.exe, you can use the following commands to see what you can use:
a.) netsh trace help: This command shows a general list of what ‘trace’ has to offer
b.) netsh trace show scenarios: This command shows you all the available ‘pre-built’ scenarios that are available for tracing purposes.
When you run the above command, you will notice a scenario called “InternetClient”. This scenario is going to be helpful to understand network traffic that is being sent/received over the network.
c.) netsh trace show scenario InternetClient: This command will show you a list of all the providers that are included in that scenario.
For example: You will notice that the above command will list an output which contains:
Provider:
Name: <Provider Name>
Provider Guid: <Provider GUID>
Default Level: <Level of tracing>
Default Keywords: <Keywords>
For most of the general troubleshooting and analysis you will need to perform on your Windows RT tablet, you can use the InternetClient scenario, but you can also aggregate multiple scenarios together.
To collect a trace using the InternetClient scenario, simply run the following command from an “elevated” command prompt (Run as administrator):
netsh trace start scenario=InternetClient capture=yes
Running this command will start tracing the scenario and will output the status of running the command. A typical output of running this command will look like this:
C:\>netsh trace start scenario=InternetClient capture=yes
Trace configuration:
-------------------------------------------------------------------
Status: Running
Trace File: C:\Users\<YourUser>\AppData\Local\Temp\NetTraces\NetTrace.etl
Append: Off
Circular: On
Max Size: 250 MB
Report: Off
Once the tracing starts, the next step for you is to reproduce the issue you are troubleshooting.
When you are done with the repro, you can run the command: netsh trace stop to stop tracing.
A typical output of running the netsh trace stop command will look like this:
C:\>netsh trace stop
Correlating traces ... done
Generating data collection ... done
The trace file and additional troubleshooting information have been compiled as
"C:\Users\<Youruser>\AppData\Local\Temp\NetTraces\NetTrace.cab".
File location = C:\Users\<YourUser>\AppData\Local\Temp\NetTraces\NetTrace.etl
Tracing session was successfully stopped.
The two files that are generated by running the trace are: NetTrace.cab and NetTrace.etl. The NetTrace.cab is an archive that contains many files in addition to the actual trace file called report.etl. The report.etl file is the same as the NetTrace.etl file.
You can now copy the NetTrace.etl file from your Windows RT machine to a regular Windows x86/x64 machine and use Microsoft Network Monitor 3.4 on the regular Windows machine to open NetTrace.etl.
When Microsoft Network Monitor opens up the ETL file, it will contain a lot of information. After the file is opened, you will also need to ensure that Microsoft Network Monitor uses the right Parsers to show you information in a readable format. To change the default Parsers that Microsoft Network Monitor uses, choose Tools –> Options –> Parser Profiles menu option, locate the parser package named “Windows” and then choose “Set As Active”. This will be useful for decoding certain frames that the Default parser does not parse.
Also notice that the ETW trace collects information which was sent over the network. This means, if you are trying to decrypt encrypted HTTPS/SSL traffic, you won’t be able to see the raw text traffic like Fiddler would show. If you are troubleshooting problems at the HTTP protocol layer – such as HTTP headers, Cookies, response codes etc. (rather than the network layer), it would be advisable to try to reproduce the same problem over HTTP so that you can check/debug the raw HTTP traffic in the ETW trace.
A typical screenshot of opening the trace in Microsoft Network Monitor 3.4 looks like this:
In the above screenshot, the “Protocol Name” column contains the protocol that was traced, while the “Description” contains a description information of the trace provider. Filtering the trace by the “Protocol Name” will help you analyze the trace from a “Protocol” perspective
If for example you wanted to only filter on the “HTTP” protocol, just type: Protocol.HTTP in the “Display Filter” window above and your trace will now be filtered over just the HTTP Protocol. The following screenshot shows you just this:
If you wanted to look at the “actual” Network traffic in terms of the TCP SYN, SYN-ACK or TCP-IP level of information, you can use the: TCP.Port==80 Display filter to see the traffic.
The below screenshot shows you this type of information:
Notice that frame 5388, 5424 and 5432 shows the TCP-IP handshake.
These are just a few of the typical filters you can use to analyze the ETW trace using Network Monitor. The actual filter that you use for your own analysis is dependent on the issue you are trying to troubleshoot and the ports or protocols you want to filter by!
To search for custom data within the actual network trace, you can use the Display filter: ContainsBin(FrameData, ASCII, “<your Network data>”). This will actually search the network trace for any data packets containing the word “<your Network Data>”.
Note: If you are only interested in debugging HTTP/HTTPS request/response, another alternative you could use is to run Fiddler on a Windows Desktop machine and configure it to run as a reverse proxy. Once Fiddler is configured as a reverse proxy on a regular Windows machine, you can change your IE Proxy settings on the Windows RT machine and point it to the machine that has Fiddler configured to run as a reverse proxy. Then route your HTTP/HTTPS requests from the Windows RT machine through Fiddler running on the remote Windows machine to perform HTTP level of troubleshooting.
This blog should hopefully guide you to trace and analyze Network activity on your Windows RT tablet even though you do not have the traditional Network monitoring/collecting tools on the Windows RT tablet.
Follow the Windows Store Developer Solutions team on Twitter @wsdevsol. Comments are welcome, both below and on twitter.
More information:
https://www.microsoft.com/en-us/download/details.aspx?id=4865
https://msdn.microsoft.com/en-us/library/windows/desktop/dd569142.aspx
Comments
Anonymous
October 15, 2013
It's worth mentioning that you can simply run Fiddler on a Windows Desktop machine and point your Windows RT device's proxy settings at that Windows machine (this also works for WinPhone, iOS, and Android devices). This configuration was commonly used inside Microsoft for HTTPS debugging on the RT devices.Anonymous
October 16, 2013
Thanks for the feedback Eric! I have included a "Note" above stating the same.