Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Monday, June 18, 2018 2:03 PM | 11 votes
Greetings!
After installing 1803 upgrade for our Windows 10 Enterprise PC, we got some strange bug:
When user or application try to open file from shared folder with a thousands of files, it takes almost 1 minute.
We found same problem here:
Some manipulations with regestry help us, but it's weird:
Regedit
HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
add
DirectoryCacheLifetime Dword=0
FileInfoCacheLifetime Dword=0
FileNotFoundCacheLifetime Dword=0
Don't forget to reboot.
How about official fix?
All replies (14)
Monday, June 18, 2018 5:38 PM
Is the server in question Windows Server 2008?
Tuesday, June 19, 2018 3:22 AM
Hi,
This is a helpful workaround and don't forget to back up the registry before you modify it.
Since there is some similar issue like "can't access exe file in shared folder","application in shared SQL not work", that is because the smb is changed in windows 1803.
We have talk to product group to confirm your issue, if there is any update , I will let you know.
And make sure that you have installed all windows update, which may released fixes in the following days.
Thanks for your feedback and understanding.
Best regards,
Vivian
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Tuesday, June 19, 2018 5:14 AM
Hi, The_Techguy.
No, it's about 2012R2 server.
Tuesday, June 19, 2018 6:16 AM
Hi, vivian_zhou.
Thank you. We will wait for fix.
Can you give more info about SMB changes in 1803?
Tuesday, June 19, 2018 7:17 AM | 1 vote
Hi,
Here are some smb issue in Technet Forum recently after windows 10 1803 released. These are part of hot issue, if you want to know more, search the key word in the forum.
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Wednesday, August 8, 2018 10:34 AM
helps for me ... it took me 3 days even to know it was 1803 that caused the problem
made the keys and now working fine
Tuesday, October 23, 2018 8:41 PM
Alexey, you are awesome! Thanks for this! We have an old app which relies on an SMB share and slowed way down with 1803. Most SMB issues out there are surrounding the v1 problem, but ours is v2.1 and was concerning slowness. These cache timeout settings are the golden ticket! Thank you, thank you, thank you!
Thursday, December 6, 2018 7:20 PM
I agree.
File copying worked way better in even Windows 3.x - the newer the Windows, the slower the copy.
I wonder if Microsoft will ever dare say $10 for every bug found...
Wednesday, January 9, 2019 9:42 PM
Any update please?
Wednesday, January 30, 2019 7:04 PM
Many thanks for this solution. Worked great.
Wednesday, July 3, 2019 9:49 AM | 2 votes
Thanks, I can confirm that adding these registry keys fixed the problem for me.
I had several network folders with Gigabytes of files in each and they would take ages to open while using windows 10. opening on windows 7 was fine. this was causing an application to hang frequently.
After adding these registry Dword values i could click on folders and they would instantly open.
I copied the below text into a .reg file and double click to merge.
****************************
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"DirectoryCacheLifetime"=dword:00000000
"FileInfoCacheLifetime"=dword:00000000
"FileNotFoundCacheLifetime"=dword:00000000
Friday, November 8, 2019 8:46 PM
Thanks for sharing the solution. It works in my lab as well. It seems Microsoft has released an official solution: https://support.microsoft.com/en-us/help/4504548/slow-network-share-performance-using-windows-10-1803s
Tuesday, December 3, 2019 2:18 AM
We've been deploying Win10 1809 for the last month - 1809 did not fix these issues and we still needed to apply the 3x CacheLifetime reg keys
Saturday, July 18, 2020 9:48 AM
Just got the 2004 update on my machines in my test environment; some machines still work OK with my Linux-based NAS drives (as mapped drives), others are very slow to contact and copy files (even 1kB text files). Found the answer on Spiceworks - enforce NetBIOS in TCP/IPv4 properties>Advanced. Works a treat. Other machines don't need it, so am bewildered somewhat as to what's happened with the 2004 build. Another issue occurring since 2004 update is that mapped drives suddenly won't connect, I can ping and access via HTTP, but Win10 will not see the drive at all. Need to disconect, restart WIn10 and map again. Have tried SMB/NFS, even a registry tweak, but still no joy. Will be interesting to see if the force NetBIOS affects that at all.