Windows Enterprise Client Boot and Logon Optimization – Part 21, Infrastructure and Settings – Network
This post continues the series that started here.
Earlier in this post series, I’ve discussed the importance of client system proximity to server resources. Whether the client is retrieving group policy data from a Domain Controller or loading a roaming user profile, it’s important that the network conversations occur quickly.
Sometimes, you may be investigating a boot trace and have some uncertainty as to whether the client system is communicating on the network at all. Fortunately, Windows Performance Recorder (WPRUI) provides the ability to capture network information and using Windows Performance Analyzer (WPA) , you can create a graph that illustrates network throughput.
Boot Trace Capture
As with all analysis traces I’ve shown earlier, I’ll suggest you use Windows Performance Recorder (WPRUI) but this time, with an extra option selected, Networking I/O activity –
You’ll need to keep in mind that this will significantly increase the size of the boot trace. A test run on my own Windows client system resulted in a trace of around 1.4 GB. For this reason, only use this option if correlating network activity with the boot phases is important.
Boot Trace Analysis
After opening the analysis trace in WPA, I get started by opening the Generic Events graph. I want to change the graph type from a checkpoint graph to a histogram. To achieve this, I’ll change the column that lies to the right of the blue bar –
From 
to 
Next I want to aggregate events in a way that will make them useful to my analysis. I order the columns to the left of the golden bar as follows –
My goal is to correlate network activity on the wire to other graphs I may be examining in my trace. Having a look through the list of providers, I come across Microsoft-Windows-TCPIP and after I expand this provider, I notice Task Names of TcpDataTransferReceive and TcpDataTransferSend –
This seems like the data I’m interested in and I want to filter the graph so that it only displays these events. To do so, I click the gear icon at the top of the graph –
This opens the Generic Events View Editor after which I click Advanced –
Here I’ll enter an event filter for the Task Names I’m interested in and click OK a couple of times to get back to my graph –
Now that I’ve filtered down to the events I want, I’ll remove Provider Name from the Generic Events table –
Lastly, I’d prefer a histogram to a line graph so I’ll select the chart type button at the top of the Generic Events graph and choose Stacked Bars with a very tight interval –
Now I have a graph that illustrates how network I/O correlates to by boot phases –
Network Trace
Based on what I may deduce using the technique above, it may be necessary to gather a network trace for analysis in Microsoft Message Analyzer. To achieve this at boot time, I can use the following command before rebooting –
netsh trace start persistent=yes capture=yes tracefile=C:\Traces\NetworkTrace.etl
And the following command after rebooting –
netsh trace stop
The resulting NetworkTrace.etl file may be opened in Microsoft Message Analyzer for typical network analysis.
Conclusion
Today I’ve discussed a method you might use to correlate network activity with Windows boot phases. This is useful to determine whether there is some delay before network communications start or if they pause somewhere in the boot/logon process.
If a network problem is suspected, a full network trace may be recorded over a reboot using netsh and analysed with Microsoft Message Analyzer.
Next Up