2 votos

La aplicación iniciada de la unidad de red se bloquea de forma aleatoria en Windows 10 (1703/1809), se notifica una excepción o error 0xc0000006 "No se puede procesar el error"

Introducción

En Windows 10 (actualización de 1703 o de 1809), las aplicaciones lanzadas desde una unidad de red se bloquea después de período de 60 a 95 minutos. En aplicaciones de Windows 7 funciona perfectamente.

El comportamiento ha sido en virtud de laboratorio para la vigilancia de varias semanas, con la participación tanto de varios de 32 bits y aplicaciones de 16 bits.

Los síntomas

  • Todos los intentos para lanzar aplicaciones desde la red de la unidad de éxito;
  • Todos los afectados de 32 bits aplicaciones EXE/DLL (Powerbuilder) ha iniciado una 0xc0000006 excepción en el Visor de Sucesos.
  • En aplicación de 16-bit (Foxpro 2.6 para MS-DOS), se produce el error "no se puede procesar el error", o simplemente se rompe y sale.
  • De vez en cuando "Fatal error 104 al intentar informe de error 104" se ha producido.
  • El fallo ocurre incluso durante un uso continuado (no significativo periodo de inactividad se produce);
  • El fracaso sólo se produjo en Windows 10 32 bit/64 bit estaciones de trabajo, ya sea en ejecución de la Actualización de 1703 o Actualización de 1809. Windows 7 estaciones de trabajo fueron bien.
  • Se reunieron puntos de análisis a la "segura" al azar período de 60 a 95 minutos entre el primer lanzamiento y rotura se produce;
  • El uso de Wireshark, error STATUS_NETWORK_SESSION_EXPIRED es iniciado constantemente en la falla ocurre en algunos escenarios.
  • Cuando varias instancias se pusieron en marcha en diferentes momentos, todos fracasaron en el mismo segundo;
  • Un ejemplo del lanzamiento de una unidad local funciona bien, incluso después de una eventual falla en la unidad de red lanzó instancias;
  • Todos afectada sitios de servidores que se ejecutan en Windows 2016 Servidor;
  • Unidad de red parece funcional después de la falla;
  • La conectividad de la red parece que nunca falla continua (PINGs) antes, durante o después de la aplicación de los descansos;

Prueba de laboratorio de las configuraciones del sistema

  • Windows Server 2016 Essentials (1607)
  • Windows 10 32 bits / 64 bits (actualización de 1703 / 1809)
  • Windows 7 (32 bits solamente)
  • Cable
  • Interruptor de

Configuración de red del servidor

Resultados de Powershell Get-SMBServerConfiguration comando:

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

Estación de trabajo de configuración de red

Resultados de Powershell Get-SMBClientConfiguration comando:

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

Lo que ya había hecho

  • Comprueba el Visor de Sucesos, incluso en SMBCLIENT y SMBSERVER sub-eventos, pero incapaz de encontrar la correlación entre los eventos y el fallo de la aplicación.
  • Trató de configuración SMB SessionTimeout ajuste a 65535 en la estación de trabajo siga por el reinicio, como se señalaba en harryc;
  • Trató de configuración SMB Keepcon ajuste a 65535 en la estación de trabajo siga por reiniciar;
  • Movilidad de desconexión automática (cambio a -1) seguido de un reinicio;
  • Intentado habilitar SMB1 en servidor/estación de trabajo seguido por un reinicio;
  • Intentado desactivar el antivirus (ESET) en servidor/estación de trabajo seguido por un reinicio;
  • Movilidad powersaving de red en la tarjeta de servidor/estación de trabajo seguido por un reinicio;
  • Intentado desactivar el firewall en el servidor/estación de trabajo;
  • El caso ha sido objeto de laboratorio supervisión de semanas sin éxito.

Hay alguien que enfrentan los síntomas y capaces de ofrecer soluciones alternativas?

Gracias por su atención

1voto

Robin Yang Puntos 11
  1. Si cualquiera de servidor/cliente de caja se ejecutan en VMWare, por favor, la actualización de las herramientas de VMware para 9.0.13 o superior. El vmxnet3 el controlador de Ethernet, como parte de las herramientas de VMware paquete, debe ser 1.5.2 o por encima, de lo contrario puede colocar los paquetes al azar sin ninguna razón.
  2. ¿Tienes algún firewall o un equilibrador de carga sentado en el medio? Por favor, por-pasa entonces a ver cómo va.
  3. El aumento de la SESSIONTIMEOUT, mencionado por harrymc, es un buen enfoque. Voy a hacer lo mismo. Pero también voy a hacer estas propósito de realizar la prueba:

Descarga TCP Optimizer 4.0, cambiar esta configuración en cliente y servidor lados del reinicio ambos cuadros: Aumentar MaxConnectionsPer1_0Server y MaxConnectionPerServer a 240, Aumentar Max SINCRONIZACIÓN de las Retransmisiones de 7 MaxUserPort 65534 TCPTimedWaitDelay a 180

Inicio de sesión de cliente de caja, montaje de la unidad de red por su dirección IP como \192.168.100.xxx\Source_folder, a continuación, ejecutar la misma aplicación para la prueba.

Si el problema continúa, por favor, comparta lo que la aplicación se está ejecutando. Si es una aplicaciones Java, se pueden requerir algunos ajustes. Deseo suerte y deseando saber cómo va.

1voto

Louis Puntos 121

En general, un nuevo error se introdujo en Windows 10 1809, reconoció por Microsoft en el artículo
Unidad de red asignada, puede que no vuelva a conectar en Windows 10, la versión de 1809.

Mientras que Microsoft es consciente del problema, una solución permanente no se hace esperar hasta que en algún momento en el año 2019. En el ínterin, si este es tu problema, usted puede utilizar la solución ofrecida en el artículo para mitigar el error.

A continuación he enumerado algunas otras soluciones propuestas por los usuarios en los foros de Internet.


Intenta establecer en el cliente el valor de SessionTimeout a 65535 segundos. Esto se puede hacer usando el comando de PowerShell Set-SmbClientConfiguration -SessionTimeout.

También puede vivir en el registro en
HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\ LANMANWORKSTATION\PARAMETERS\SESSTIMEOUT
(ver este enlace antiguo).

Sugiero reiniciar después.


Otras posibles soluciones:

  • El cambio de la directiva de grupo para Actualizar en lugar de Reemplazar la unidad de asignación, en el Objeto de Directiva de Grupo (GPO): Configuración De Usuario > Preferencias > Configuración De Windows > Unidad De Mapas. Ver enlace. Algunas personas dicen que puede ser configurado para Actualizar.

  • Ejecutar en el servidor y el cliente en elevados cmd el comando:

    net config server /autodisconnect:-1
    
  • Establezca la opción de alimentación del adaptador de red deshabilitar ¿ "Permitir que el equipo apague este dispositivo para ahorrar energía".

  • Algunas personas informan de que la reasignación del recurso compartido de red en el inicio de sesión resuelve el problema, y algunos han añadido un script de inicio de sesión para que.

  • Otros informes se recomienda deshabilitar Windows 10 inicio rápido.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: