As far as I can tell, there appears to be a problem with applications crashing after running for 60 to 95 minutes on Windows 10 (specifically updates 1703 or 1809) when they are launched from a network drive.
Interestingly, this problem does not seem to occur when running the same applications on Windows 7.
We have been monitoring this issue in our lab for several weeks and have observed it happening with both 32-bit and 16-bit applications.
Symptoms
As I’ve been investigating the issue, I’ve noticed the following symptoms:
– All attempts to launch applications from the network drive succeed initially.
– However, all affected 32 bit applications EXE/DLL (Powerbuilder) show an 0xc0000006 exception in the Event Viewer.
– On the 16 bit application (Foxpro 2.6 for MS-DOS), an error message saying “Unable to process error” occurs or the application simply breaks and exits.
– Occasionally, a “Fatal error 104 while attempting to report error 104” occurs.
– The failure happens even during continuous usage, without any significant inactivity period.
– The issue only occurs on Windows 10 32 bit/64 bit workstations running Update 1703 or Update 1809. Windows 7 workstations seem to be unaffected.
– From my analysis, it seems that a “safe” random period between 60 to 95 minutes occurs between the first launch and the break.
– By using Wireshark, I consistently see the error message “STATUS_NETWORK_SESSION_EXPIRED” logged when the failure occurs in some scenarios.
– When several instances are launched at different times, they all fail at the same second.
– An instance launched from a local drive runs fine, even after an eventual fail on network drive launched instances.
– All affected server sites are running on Windows 2016 Server.
– The network drive seems functional after the failures.
– 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
So far, we have tried several troubleshooting steps to address the issue, including checking the Event Viewer but we could not find any correlation between the events and the application failure. We also attempted to set the SMB SessionTimeout and Keepcon settings to 65535 on the workstation and disabled autodisconnect, enabled SMB1, disabled antivirus, and disabled the powersaving network on both server and workstation, followed by a reboot.
Additionally, we also tried to disable the firewall on both server and workstation, but the issue persisted. Despite our efforts, the problem remains unsolved, and we are still experiencing the same symptoms.
If anyone else has encountered similar issues and has found alternative solutions, please let us know. We appreciate your attention to this matter.
2 Answers
As I understand it, there is a bug in Windows 10 1809 that has been acknowledged by Microsoft.
The bug causes mapped network drives to fail to reconnect, which can be a significant issue for users. While Microsoft is aware of the problem, it seems that a permanent solution won’t be available until sometime in 2019.
In the meantime, there is a workaround suggested in the article that should help mitigate the bug. I’ve also been looking into other workarounds that have been proposed by users on various internet forums.
To potentially address the issue, it is recommended to set the value of SessionTimeout to 65535 seconds on the client. This can be accomplished through the use of a PowerShell command, specifically the Set-SmbClientConfiguration -SessionTimeout command.
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.