Solving terrible performance in application using folders with high filecount

Sometimes you get those fun issues, where applications are not behaving as they should, or in this case, performing terrible.
Read on to get information on what fixed the issues with terrible performance for a file based windows application in this case.


Recently I was troubleshooting terrible application performance for a windows application.
This application uses files and directories located on a file server.
The file server OS was Windows server 2016 and the clients are Windows Server 2019 Citrix terminal servers.

The application uses seperate client folders containing files pr client, with alot of files inside the various folders – some more than others.
In this specific there were tens of thousands of files in some client folders.
Performance on the application was intermittently slow, and it could take upto 15 minutes to switch between one client and another inside the application

Troubleshooting terrible performance

While checking logs, performance etc on the client/worker side as well as the server side did not show any particular causes for this.
The windows performance monitor, and various sysinternals tools where used to look a little deeper on the issue, but gave no immediate cause.

Changing the following settings were attempted on the Client/server side:
Using powershell to some changes to the SMB configuration and registry for others.

# On the server hosting the share(s):
# to check current settings: 
Get-SmbServerConfiguration |select enablemultichannel, enableoplocks, serverhidden, irpstacksize, maxmpxcount, maxworkitems,maxsessionperconnection,treathostasstablestorage
# To change settings: 
Set-SmbServerConfiguration -IrpStackSize 20 -force #(Default 15)
Set-SmbServerConfiguration -MaxMpxCount 4096 -force #(Default 50)
Set-SmbServerConfiguration -MaxWorkItems 16384 -force #(Default 1)
Set-SmbServerConfiguration -TreatHostAsStableStorage $true -force #(default $false)
# On the client(s) accessing the share(s):
# To check current settings: 
Get-SmbClientConfiguration |select enablebandwidththrottling, enablelargemtu, enableloadbalancescaleout,enablemultichannel,enablesecuritysignature,maxcmds, maximumconnectioncountperserver,oplocksdisabled,requiresecuritysignature,useopportunisticlocking,windowsizethreshold
# To change settings: 
Set-SmbClientConfiguration -EnableBandwidthThrottling $false -force (Default $true)
Set-SmbClientConfiguration -EnableSecuritySignature $false -force (Default $true)
Set-SmbClientConfiguration -MaxCmds 16384 -force #(Default 50)
Set-SmbClientConfiguration -WindowSizeThreshold 2 -force #(Default 1)
# adding AdditionalCriticalWorkerThreads in registry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Executive
AdditionalCriticalWorkerThreads = 64 # Default is 0

The above did not seem to help for this case.
Next step was to disable “8 dot 3” name creation.
This was done on server and client side.

This is done by modifying the DWORD located in the registry here:

NtfsDisable8dot3NameCreation = 1 #Default is 2

More info on that record here
This should not be needed on up to date apps.

This did also not change anything for the better in terms of application performance.

The solution

Searching further for possible causes this article was found:
And one of the notes there gave some hints:


A known issue in Windows 10, version 1803, affects the ability of Windows 10 to cache large directories. After you upgrade a computer to Windows 10, version 1803, you access a network share that contains thousands of files and folders, and you open a document that is located on that share. During both of these operations, you experience significant delays.To resolve this issue, install Windows 10, version 1809 or a later version.
To work around this issue, set DirectoryCacheLifetime to 0.
This issue affects the following editions of Windows 10:

  • Windows 10 Enterprise, version 1803
  • Windows 10 Pro for Workstations, version 1803
  • Windows 10 Pro Education, version 1803
  • Windows 10 Professional, version 1803
  • Windows 10 Education, version 1803
  • Windows 10 Home, version 1803

This in turn lead to this article recommending to change the following by registry.
DirectoryCacheLifetime = 0
FileNotFoundCacheLifetime  = 0
FileInfoCacheLifetime = 0

This is also mentioned in this discussion on spiceworks, recommending changing these 2:
DirectoryCacheLifetime  = 0
FileInfoCacheLifetime  = 0

These values can be added here in the windows registry
DirectoryCacheLifetime  DWORD = 0
FileInfoCacheLifetime   DWORD = 0 

After these were added on the clients accessing the shares, application performance got normal.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from

Subscribe now to keep reading and get access to the full archive.

Continue reading