Slow initial shared folder reading exactly each 3 minutes?

[ShadowHunter]

Hello Hexus members,

First time poster from Belgium.

This problem I have is starting to obsess me, for days I have been trying to find the root cause... alas my current knowledge seems to be insufficient hence I turn to this helpful community.

Setup: Windows 2012R2 (not as DC) , on it a few shared folders, plain and simple. The clients are all Windows 7 (in Workgroup) and access the shares with a server account.

All clients are wired connected to the server. Copy speeds between shares and client are fine: +/-97 Mb/sec.

Problem: When opening Windows Explorer it takes approx. 30 seconds to read the shared folder contents. Once loaded all works smooth and as expected. However after exactly 3 minutes of inactivity in Explorer it needs again 30 seconds loading time

I already tried a myriad of things: disabling virus scanners, firewall on both ends, change HDD (WD Black) spindown time, Advanced NIC settings as RSS, disabled autodisconnect (netsh int tcp...), autotuninning and tons of those. Nothing seems to fixed it.

Yet I'm sure I'm looking for a too complex root cause, the clue must be in those exact timed 3 minutes!

What oh what can those 3 minutes possible mean?

Thank you so much for any pointers.

With best regards,

ShadowHunter

[TeaLeaf]

Is this the slow 'green bar' on file explorer? I have several large folders that used to do that too.

Try using Folder Properties to customise the folder to suit the types of files, .e.g documents. This will stop it trying to generate a lot of previews & thumbnails etc which are sometimes not needed. Make sure you also apply to the sub-folders.

[ShadowHunter]

Thanks for your feedback TeaLeaf

It alas happens with small and large folders. I changed the folders and all subfolders to "General Items" but no change...

[RobbieRoy]

Perhaps you're reading too much into the 'exactly 3 minutes' as that rounded time could simply be a coincidence. What is more relevant is that it takes exactly the same time in each repetition of the problem. Sounds like it could be something like a set time out process due to perceived inactivity.

[ShadowHunter]

Yes... it must be something timing out but I'm clueless on what. You might be right about the 3 minutes... I remember that some months ago initial reading was faster (slow but still faster than today)

I timed those 180 seconds at least 10 times with a stopwatch on two different machines but all within the same day.

[smargh]

For this problem, this is usually the list of thing to check:

1) DNS
2) DNS
3) DNS

Then go back to #1 in case you forgot to check something.

[ShadowHunter]

To avoid DNS issue I have mapped the shares on the client via IP \\192.168.1.115\c$, can this still give DNS trouble?

[Bonebreaker777]

To avoid DNS issue I have mapped the shares on the client via IP \\192.168.1.115\c$, can this still give DNS trouble?

Personally I would say it shouldn't but pff what do I know about networking

Can't be that auto-discovery thing in Windows 7 which produces a peak in ping time in pretty much the same intervals?

[Splash]

How many items are there in this shared folder? If you create another share on the same server but with only a couple if items in (just for test purposes, really) do you see the same issue? How about if you access the share from the server itself - same issue?

[ShadowHunter]

Locally it show instant the folder contents... after some investigation I found that ESET Endpoint firewall is after all causing the delay.

Currently it is set in Interactive mode, when switched to Automatic the delay is gone. Previously I said the problem remained with firewall off but it seems I have to wait a bit after I switch it off which at first I didn't (I hurried the test since I don't like to be on the web unprotected)

Now I'm looking into the rules what is blocking the request... so far no luck. The logs are also not much of help. To be continued...

[bytejunkie]

some garbled recollections of similar issue i looked at recently.

windows will be trying to read the folder using RPC. so it sees it as a SMB share and uses its own flavour of SMB encapsulated in RPC, then after that fails, itll drop back to proper SMB, version 2. ensure that RPC is open, think this is gonne be 145 339 and 445.

like i said, garbled recollection. but it might give you some clues.

[ShadowHunter]

@bytejunkie

Sir, I humbly bow before thou

It seems the problem has been resolved.

After putting the firewall log to maximum verbosity and some filtering I saw an outgoing communication being dropped on port 445. Even though port 445 and range 137-139 for SMB over TCP were open for the internal network...

However I noticed a suspicious custom rule blocking all outgoing communication from the system process. Once this rule was disabled the slow reading disappeared and there were no more drops.

Probably during some experimental phase the rule was created in the interactive mode (clicking DENY too soon)... I cannot think of any other reason. It does explain though why it worked in the past without this delay.

Anyhow, thanks to your tip I was finally looking in the right direction. I hope this post can help others as well

ShadowHunter