Windows – Debugging slow SMB packets from a specific desktop client

broadcomserver-message-blockwindowswireshark

I'm having some serious problems locating a slowdown, and I hope you could assist me with this.

We have an office network with ~50 clients and a main file server running Windows Server 2008 R2 Standard (SP1). For one specific client (Windows 7, SP1) accessing the network shares can become painfully slow at times, and this can only be fixed by restarting the computer. Now the problem is that we have switched out the actual computer and the problem still persists. The new computer is of the same make and model, but we have a number of those in the office and they have not experienced this problem.

Have also tried to change all the related network cables, as well as using different ports on the switch. I've also tried logging in as a different AD user to no avail.

I've ran WireShark on the client computer as well as my own for comparison and the SMB packets are 10-1000 times slower on the affected computer, however only while being sent to the file server. All SMB packets sent to the server (from my test computer as well as the affected one) have a bad header checksum, if that matters.

This is not my main area of expertise, and so am I am having a hard time parsing the WireShark log except by comparing it to a different one and seeing the differences in elapsed time between packets. Basically I'm not sure where to look for a problem cause, just the effects.

Below are statistics of the bytes-per-tick for the two computers, for some basic navigating around and copying a small (~100kb) file to the desktop from the network disk. Doing the same thing over FTP yields normal results for both computers.

http://www.kommunicera.se/public/bytes-per-tick.png

PCAP files are here (small) and here (big).

Note that the two dumps in pcap-2.zip are from the same computer, but one is when it's acting normal and one when it's experiencing slowdowns (dumps captured minutes apart).

Best Answer

Figure I'd update this with the solution we ended up with.

For some reason the specific Broadcom NIC driver we had was causing this problem - all the computers affected had the same NIC and the same driver version. Updating to the latest driver solved the entire issue.

Related Topic