Hello again AskPerf! This is Austin. In my last post, we discussed how to get a network trace using OneClick. Today, I’m going to show you how you might use that data. The example I am going to use is for a file server that is acting sluggish and show you how two registry values might alleviate some of your issues. Don’t worry, we’re not going to start another chorus of “Get Rid of those .PST Files” – we’re going to assume that you’re in a .PST-free zone today! Let’s take our network capture that we got from our OneClick session. We are going to use Wireshark to do a two-minute analysis on our capture file.
Open up your .CAP file in Wireshark. Once the capture file is loaded, click on Statistics, then Protocol Hierarchy. This provides you with a breakdown of your network traffic. When investigating sluggish file server issues, one of the things we look for is whether or not there is a disproportionate amount of Server Message Block (SMB) traffic – file / folder access type traffic.
In this capture we can see that well over 60% of the Network traffic is being generated by SMB. The rest of the traffic percentage is the TCP overhead to encapsulate the packet. Now let’s figure out if the SMB traffic is being caused by Change Notify requests. Change notify requests are folder / file query requests when a change occurs to auto-refresh Windows Explorer. Most folks notice this on Windows XP systems when their Windows Explorer screen seems to be flickering – because it’s auto-refreshing. Let’s see if that’s what is really happening here. To view the SMB details in Wireshark, click Statistics, then Service Response Time, SMB and then Create Stat. Below is the SMB breakdown from our problem scenario:
Looking at this breakdown, we can see than over 50% of the traffic is Trans2 commands. 90% of the Transaction2 sub-commands are are QUERY_FILE_INFO and QUERY_PATH_INFO. Translation? Something changed and Windows Explorer is refreshing its view … a lot!
As you can see, with a simple network trace and a couple of minutes work we’ve figured out where most of the traffic is coming from. So how do we fix this? Enter our two registry values:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\explorer NoRemoteRecursiveEvents=1 (Dword) NoRemoteChangeNotify=1 (Dword)
If the majority of the Trans2 Sub-Commands had been QUERY_PATH_INFO, we could have gone ahead and only enabled caching for all files and folders as opposed to both of the registry values above. This would preserve the Auto-refresh feature in Windows Explorer, as opposed to the user having to use the F5 key to refresh the view (which is what you had to do in Windows 2000). To enable the caching, set the registry value below:
HKLM\SYSTEM\CurrentControlSet\Services\MrxSmb\Parameters InfoCacheLevel=10 (hex Dword / 10 – Enables caching for all files and folders )
Alternatively, you could use the registry value above in conjunction with the NoRemoteRecursiveEvents entry so that some Windows Explorer refreshes happen automatically. To dig into what files are being accessed by QUERY_PATH_INFO, you can set up a query in WireShark. The query for this is: smb.trans2.cmd==0x5. One thing to note here is that SMB refers to SMB 1.0 – not SMB 2.0. When examining the traces in WireShark or Network Monitor, keep in mind what version of SMB you are seeing. You could also see what type of files are being accessed by using the following WireShark query: smb.file contains "\\".
With that, it’s time to bring this post to a close. Hopefully you are able to use this information to perform more in-depth investigations of what ails your file servers!
– Austin Mack
|Share this post :|