Revision history [back]

Hello thetechfirm

Short answer

It looks like two different processes access the same file, or a single process opens the file multiple times. And not to forget the possibility of two threads in the same process.

The behavior documented by Wireshark may be caused by an anti virus program, or it could be the programmed behavior of the application.

Technical background

Before any application can access data on a file server, the client has to run through a number of steps. The major ones are:

• The client has to establish a SMB session. This includes the negotiation of the SMB dialect, credential checks etc.
• The client has to specify a share, where the desired files are stored
• You might notice a couple of other steps, e. g. DFS related transactions, notify requests etc.

Once all this has been sorted out the client has to tell the server name and directory of the desired file. This happens with the "Create Request". The Create Requests returns a GUID, which will be used by the client for later reference. The client will present the GUID in the read statement. As soon as the application closes the file we can see a Close Request on the wire. Please note that Wireshark replaces the GUID with the file name for your convenience.

Your screenshot shows two series of Create / Read / Close transactions.

• Please check, if each series of Create / Read / Close refers to a different GUID
• I would expect different GUIDs
• To me, this is proof that we really have two independent read transactions.

Analysis tip: Create a coloring rule for each file GUID to highlight activities for a specific file.

Finding the root cause

Wireshark can only reveal what's transmitted. Assuming that all requests are made within the same SMB session we cannot identify the responsible application on the host.

If you expect that the virus scanner is causing the double reads, you could define an exclusion for that directory. Reboot if necessary, then run your application again. If your AV solution is responsible you should see only a single chain of Create / Read / Close events.

Security Advice: Since the AppData directory is often used to store malware I highly suggest to keep %AppData% in the list of protected directories. Never whitelist %AppData% and it's sub-directories.

If it's not your anti virus (or you cannot exclude AppData from virus scans) you need a different tool. My next step would be the Sysinternals Process Monitor. The Windows ressource monitor (command line perfmon /res) or the process monitor (command line perfmon) might help, if you are not allowed to install extra tools.

Less obvious possiblities

Just for the sake of completeness: Other options are

• The read requests refer to files with the same name, but on a different share.
• The read requests was issued by a different user (using another logon session, background process etc.) on the same computer.
• The filenames are slightly different (like swuimun and swuirnun), and I missed that detail

Given the file- and directory name from your screenshot this is less likely. Therefore I expect that the SMB2 Header for packets 685 and 696 show identical values for Tree ID and Session Id respectively.

Good luck

Eddi