Network drive launched application randomly crashes on Windows 10 (1703/1809) reporting 0xc0000006 exception or error "Unable to process error"

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

windows-10
network-shares
crash
windows-server-2016
asked on Super User Mar 26, 2019 by Julio Nobre • edited Apr 2, 2019 by davidgo

2 Answers

2

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.

answered on Super User Mar 29, 2019 by harrymc • edited Mar 29, 2019 by harrymc
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.

answered on Super User Mar 28, 2019 by Robin Yang

User contributions licensed under CC BY-SA 3.0