☰

O aplicativo iniciado pela unidade de rede trava aleatoriamente no Windows 10 (1703/1809) relatando exceção ou erro 0xc0000006 "Não foi possível processar o erro"

tag-icon • tag-icon windows-10 network-shares crash windows-server-2016
O aplicativo iniciado pela unidade de rede trava aleatoriamente no Windows 10 (1703/1809) relatando exceção ou erro 0xc0000006 "Não foi possível processar o erro"

Introdução

SobreWindows 10 (atualização 1703 ou 1809), os aplicativos iniciados a partir de uma unidade de rede travam após um período de60para95minutos. No Windows 7, os aplicativos funcionam perfeitamente.

O comportamento está sob vigilância laboratorial há várias semanas, envolvendo vários aplicativos de 32 e 16 bits.

Sintomas

  • Todas as tentativas de iniciar aplicativos da unidade de rede foram bem-sucedidas;
  • Todos os aplicativos EXE/DLL afetados de 32 bits (Construtor de energia) registrou um0xc0000006exceção emVisualizador de eventos.
  • Em aplicativos de 16 bits (Foxpro 2.6 para MS-DOS), ocorre erro "Não foi possível processar o erro" ou simplesmente quebra e sai.
  • De vez em quando "Erro fatal 104 ao tentar relatar o erro 104" ocorreu.
  • A falha acontece mesmo durante o uso contínuo (não ocorre período significativo de inatividade);
  • A falha só ocorreu emJanelas 10Estações de trabalho de 32/64 bits executando a Atualização 1703 ou Atualização 1809. As estações de trabalho com Windows 7 funcionaram bem.
  • A análise coletada aponta para um período aleatório "seguro" de60para95minutos entre o primeiro lançamento e o intervalo;
  • UsandoWireshark, erroSTATUS_NETWORK_SESSION_EXPIREDé registrado consistentemente quando a falha ocorre em alguns cenários.
  • Quando diversas instâncias foram iniciadas em momentos diferentes, todas falharam no mesmo segundo;
  • Uma inicialização de instância a partir de uma unidade local funciona bem, mesmo após uma eventual falha nas instâncias iniciadas em uma unidade de rede;
  • Todos os servidores de sites afetados estão em execuçãoServidor Windows 2016;
  • A unidade de rede parece funcional após falha;
  • A conectividade de rede parece nunca falhar (PINGs contínuos) antes, durante ou após interrupções do aplicativo;

Configurações de sistema de laboratório testadas

  • Fundamentos do Windows Server 2016 (1607)
  • Windows 10 32 bits/64 bits (atualização 1703/1809)
  • Windows 7 (somente 32 bits)
  • Cabo
  • Trocar

Configuração de rede do servidor

Resultados do comando do Powershell Get-SMBServerConfiguration:

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

Configuração de rede da estação de trabalho

Resultados do comando do Powershell Get-SMBClientConfiguration:

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

O que já tínhamos feito

  • VerificadoVisualizador de eventos, mesmo em subeventos SMBCLIENT e SMBSERVER, mas não foi possível encontrar correlação entre eventos e falha do aplicativo.
  • Tentei configurar SMBSessão expiradaconfiguração para65535na estação de trabalho, siga pela reinicialização, conforme apontado porHarry;
  • Tentei configurar SMBKeepConconfiguração para65535na estação de trabalho, reinicie;
  • Desconexão automática desativada (alterando para -1) seguida de reinicialização;
  • Tentei ativarPME1no servidor/estação de trabalho seguido de uma reinicialização;
  • Tentei desabilitar o antivírus (ESET) no servidor/estação de trabalho seguido de uma reinicialização;
  • Rede de economia de energia desativada na placa, tanto no servidor quanto na estação de trabalho, seguida de reinicialização;
  • Tentei desabilitar o firewall no servidor/estação de trabalho;
  • O caso está sob vigilância laboratorial há semanas, sem sucesso.

Há mais alguém enfrentando os sintomas e capaz de fornecer soluções alternativas?

Obrigado por sua atenção

Responder1

Em geral, um novo bug foi introduzido no Windows 10 1809, reconhecido pela Microsoft no artigo
A unidade de rede mapeada pode não conseguir se reconectar no Windows 10, versão 1809.

Embora a Microsoft esteja ciente do problema, uma correção permanente não é esperada até algum momento de 2019. Enquanto isso, se esse for realmente o seu problema, você pode usar a solução alternativa oferecida no artigo para mitigar o bug.

Abaixo listei algumas outras soluções alternativas propostas por usuários em fóruns da Internet.

Tente definir no cliente o valor de SessionTimeout65.535 segundos. Isso pode ser feito usando o comando PowerShell Set-SmbClientConfiguration -SessionTimeout.

Ele também pode estar no registro em
HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\ LANMANWORKSTATION\PARAMETERS\SESSTIMEOUT
(veja estelink antigo).

Sugiro reiniciar depois.

Outras soluções alternativas possíveis:

  • Altere a política de grupo paraAtualizarem vez deSubstituiro mapeamento da unidade, no Objeto de Política de Grupo (GPO): Configuração do usuário > Preferências > Configurações do Windows > Mapas de unidade. Verlink. Algumas pessoas relatam que pode ser configurado paraAtualizar.

  • Execute no servidor e no cliente em cmd elevado o comando:

    net config server /autodisconnect:-1

  • Defina a opção de energia do adaptador de rede e desative "Permitir que o computador desligue este dispositivo para economizar energia".

  • Algumas pessoas relatam que o remapeamento do compartilhamento de rede no login resolve o problema, e alguns adicionaram um script de login para isso.

  • Outros relatórios recomendam desativar a inicialização rápida do Windows 10.

Responder2

  1. Se alguma caixa de servidor/cliente estiver em execução no VMWare, atualize as ferramentas VMware para 9.0.13 ou superior. O driver Ethernet vmxnet3, como parte do pacote de ferramentas VMware, deve ser 1.5.2 ou superior, caso contrário, poderá descartar pacotes aleatoriamente sem motivo.
  2. Você tem algum firewall ou balanceador de carga intermediário? Por favor, ignore-o e veja como vai.
  3. Aumentar o SESSIONTIMEOUT, mencionado por harrymc, é uma boa abordagem. Eu vou fazer o mesmo. Mas também farei isso para fins de teste:

Baixe o TCP Optimizer 4.0, altere essas configurações nos lados do cliente e do servidor e reinicie ambas as caixas: Aumente MaxConnectionsPer1_0Server e MaxConnectionPerServer para 240, Aumente Max SYNC Retransmissions para 7 MaxUserPort para 65534 TCPTimedWaitDelay para 180

Na caixa do cliente de logon, monte a unidade de rede por seu endereço IP como \192.168.100.xxx\Source_folder e execute o mesmo aplicativo para testá-lo.

Se o problema persistir, compartilhe qual aplicativo você está executando. Se for um aplicativo Java, pode exigir alguns ajustes. Desejo-lhe sorte e estou ansioso para saber como vai ser.

informação relacionada