3

Introduction

On Windows 10 (update 1703 or 1809), applications launched from a network drive crashes after period of 60 to 95 minutes. On Windows 7 applications runs flawlessly.

Behaviour has been under lab surveillance for several weeks, involving both several 32 bit and 16 bit applications.

Symptoms

  • All attempts to launch applications from network drive succeed;
  • All affected 32 bit applications EXE/DLL (Powerbuilder) logged an 0xc0000006 exception on Event Viewer.
  • On 16 bit application (Foxpro 2.6 for MS-DOS), occurs error "Unable to process error" or simply breaks and exits.
  • Once in a while "Fatal error 104 while attempting to report error 104" occured.
  • Failure happens even during continuous usage (no significant inactivity period occurs);
  • Failure only occured on Windows 10 32 bit/64 bit workstations either running Update 1703 or Update 1809. Windows 7 workstations were fine.
  • Gathered analysis points to "safe" random period from 60 to 95 minutes between first launch and break occurs;
  • Using Wireshark, error STATUS_NETWORK_SESSION_EXPIRED is consistently logged at failure ocurrs on some scenarios.
  • When several instances were launched at different times, they all failed at the same second;
  • A instance launch from a local drive runs fine, even after an eventual fail on network drive launched instances;
  • All afected sites servers are running on Windows 2016 Server;
  • Network drive seems functional after fails;
  • Network connectivity never seems to fail (continuous PINGs) before, during or after application breaks;

Tested lab system configurations

  • Windows Server 2016 Essentials (1607)
  • Windows 10 32 bit / 64 bit (update 1703 / 1809)
  • Windows 7 (32 bit only)
  • Cable
  • Switch

Server network configuration

Results of Powershell's Get-SMBServerConfiguration command:

AnnounceComment                 : 
AnnounceServer                  : False
AsynchronousCredits             : 512
AuditSmb1Access                 : False
AutoDisconnectTimeout           : 999999
AutoShareServer                 : True
AutoShareWorkstation            : True
CachedOpenLimit                 : 10
DurableHandleV2TimeoutInSeconds : 180
EnableAuthenticateUserSharing   : False
EnableDownlevelTimewarp         : False
EnableForcedLogoff              : True
EnableLeasing                   : False
EnableMultiChannel              : True
EnableOplocks                   : True
EnableSecuritySignature         : True
EnableSMB1Protocol              : True
EnableSMB2Protocol              : True
EnableStrictNameChecking        : True
EncryptData                     : False
IrpStackSize                    : 15
KeepAliveTime                   : 2
MaxChannelPerSession            : 32
MaxMpxCount                     : 50
MaxSessionPerConnection         : 16384
MaxThreadsPerQueue              : 20
MaxWorkItems                    : 1
NullSessionPipes                : netlogon,samr,lsarpc
NullSessionShares               : 
OplockBreakWait                 : 35
PendingClientTimeoutInSeconds   : 120
RejectUnencryptedAccess         : True
RequireSecuritySignature        : True
ServerHidden                    : True
Smb2CreditsMax                  : 8192
Smb2CreditsMin                  : 512
SmbServerNameHardeningLevel     : 0
TreatHostAsStableStorage        : False
ValidateAliasNotCircular        : True
ValidateShareScope              : True
ValidateShareScopeNotAliased    : True
ValidateTargetName              : True

Workstation network configuration

Results of Powershell's Get-SMBClientConfiguration command:

ConnectionCountPerRssNetworkInterface : 4
DirectoryCacheEntriesMax              : 16
DirectoryCacheEntrySizeMax            : 65536
DirectoryCacheLifetime                : 0
DormantFileLimit                      : 1023
EnableBandwidthThrottling             : True
EnableByteRangeLockingOnReadOnlyFiles : True
EnableInsecureGuestLogons             : True
EnableLargeMtu                        : True
EnableLoadBalanceScaleOut             : True
EnableMultiChannel                    : True
EnableSecuritySignature               : False
ExtendedSessionTimeout                : 1000
FileInfoCacheEntriesMax               : 64
FileInfoCacheLifetime                 : 0
FileNotFoundCacheEntriesMax           : 128
FileNotFoundCacheLifetime             : 5
KeepConn                              : 65535
MaxCmds                               : 50
MaximumConnectionCountPerServer       : 32
OplocksDisabled                       : False
RequireSecuritySignature              : False
SessionTimeout                        : 65535
UseOpportunisticLocking               : False
WindowSizeThreshold                   : 8

What we had already done

  • Checked Event Viewer, even on SMBCLIENT and SMBSERVER sub-events, but unable to find correlation between events and application failure.
  • Tried setting SMB SessionTimeout setting to 65535 on workstation follow by reboot, as pointed by harryc;
  • Tried setting SMB Keepcon setting to 65535 on workstation follow by reboot;
  • Disabled autodisconnect (changing it to -1) followed by a reboot;
  • Tried enabling SMB1 on both server/workstation followed by a reboot;
  • Tried disabling antivirus (ESET) on both server/workstation followed by a reboot;
  • Disabled powersaving network on card both server/workstation followed by a reboot;
  • Tried disabling firewall on both server/workstation;
  • Case has been under lab surveilance for weeks with no success.

Is there anyone else facing the symptons and able to provide alternative solutions?

Thanks for you attention

2
  • 1
    This might help you docs.microsoft.com/en-us/sysinternals/downloads/procmon Commented Mar 26, 2019 at 10:19
  • I forgot to mention that we've also used Process Monitor, but it provided no complementary clues regarding to Wireshark info. It seems every exe/dll opened thats kept opened for more that 60 minutes is afftected. Commented Mar 26, 2019 at 12:21

2 Answers 2

2
+50

In general, one new bug was introduced in Windows 10 1809, acknowledged by Microsoft in the article
Mapped network drive may fail to reconnect in Windows 10, version 1809.

While Microsoft is aware of the problem, a permanent fix isn't expected until sometime in 2019. In the meantime, if this is indeed your problem, you may use the workaround offered in the article to mitigate the bug.

Below I have listed some other workarounds proposed by users on Internet forums.


Try to set on the client the value of SessionTimeout to 65535 seconds. This can be done using the PowerShell command Set-SmbClientConfiguration -SessionTimeout.

It may also live in the registry at
HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\ LANMANWORKSTATION\PARAMETERS\SESSTIMEOUT
(see this old link).

I suggest rebooting afterward.


Other possible workarounds:

  • Change the group policy to Update rather than Replace the drive mapping, in the Group Policy Object (GPO): User Configuration > Preferences > Windows Settings > Drive Maps. See link. Some people report that it can be set to Refresh.

  • Run on server and client in elevated cmd the command:

    net config server /autodisconnect:-1
    
  • Set the power option of the network adapter do disable "Allow the computer turn off this device to save power".

  • Some people report that remapping the network share on login solves the problem, and some have added a login script for that.

  • Other reports recommend disabling Windows 10 fast startup.

5
  • We already tried that, but no success. I will update my question. Since you added an answer, please consider removing (if possible) your duplicate comment. Commented Mar 29, 2019 at 9:35
  • I have added more information.
    – harrymc
    Commented Mar 29, 2019 at 10:41
  • Changing the Group Policy to Update rather than Replace the drive mapping did solve it! Commented Mar 29, 2019 at 15:39
  • Knowing your tip enabled us to rapidly question some of our assumptions, since it allowed us to reproduce failure with a simple gpupdate command to update group policy. We also found why drive mapping replace policy was not affecting Windows 7 machine: applying gpupdate on Windows 7 required a session restart, while Windows 10 was able to apply policy immediately. I will update my question with new findings. Commented Mar 29, 2019 at 15:50
  • Just to point out that I do not agree with Windows 10 Update 1809 bug reference, since, beside ours tests proved it Update 1703 is also affected, I would classify it as different subjet. Anyway, you surelly deserve the bounty! Commented Mar 29, 2019 at 15:56
1
  1. If any of server/client box is running on VMWare, please update the VMware tools to 9.0.13 or above. The vmxnet3 Ethernet driver, as part of VMware tools package, should be 1.5.2 or above, otherwise it may drop packages randomly for no reason.
  2. Do you have any firewall or load balancer sitting in-between? Please by-pass it then see how it goes.
  3. Increasing the SESSIONTIMEOUT, mentioned by harrymc, is a good approach. I will do the same. But I will also do these for testing purpose:

Download TCP Optimizer 4.0, change these settings on both client and server sides the reboot both boxes: Increase both MaxConnectionsPer1_0Server and MaxConnectionPerServer to 240, Increase Max SYNC Retransmissions to 7 MaxUserPort to 65534 TCPTimedWaitDelay to 180

Logon client box, mount the network drive by its IP address as \192.168.100.xxx\Source_folder then run the same app to test it.

If problem keeps going on, please share what app you are running. If it is a Java apps, it may require some tuning. Wish you luck and looking forward to know how it goes.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .