Se estableció con éxito una conexión con el servidor, pero luego se produjo un error durante el inicio de sesión previo al inicio de sesión.

Recibo un error de seguimiento cuando bash conectar DB de producción desde el entorno local.

Pude conectar Production DB antes, pero de repente estoy recibiendo un error de seguimiento, ¿alguna idea?

Se estableció con éxito una conexión con el servidor, pero luego se produjo un error durante el inicio de sesión previo al inicio de sesión. (provider: TCP Provider, error: 0 – El identificador no es válido).

Estaba intentando ejecutar el sitio web asp.net en la PC local, que tiene una cadena de conexión de DB de producción, a continuación se muestra el rastro de la stack por error que estoy obteniendo en el entorno local.

en MyWebsiteDAL.clsForumQuestion.SelectAll (Int32 CurrentPageIndex, Int32 PageSize) en D: \ EDrive \ My WebSites \ MyWebsite \ MyWebsite \ MyWebsiteDAL \ clsForumQuestion.cs: línea 821 en CodeConnect.Default.Page_Load (Object remitente, EventArgs e) en D: \ EDrive \ My WebSites \ MyWebsite \ MyWebsite \ MyWebsite \ Default.aspx.cs: línea 100 en System.Web.Util.CalliHelper.EventArgFunctionCaller (IntPtr fp, Object o, Object t, EventArgs e) en System.Web.Util. CalliEventHandlerDelegateProxy.Callback (Object Sender, EventArgs e) en System.Web.UI.Control.OnLoad (EventArgs e) en System.Web.UI.Control.LoadRecursive () en System.Web.UI.Page.ProcessRequestMain (Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

¿Alguna idea de lo que podría haber ido mal aquí?

Solución

1) Limpie su solución VS.Net

2) Reconstruye el proyecto.

3) Restablecer IIS

4) Ejecuta el proyecto nuevamente.

Básicamente eso resolvió mi problema, pero en mi caso no estaba recibiendo este error y de repente mi entorno local comienza a darme el error anterior, por lo que puede ser que ese truco funcione para mí.

– Salvé mi trabajo,
– Cerrado Visual Studio, luego
– Reabrí mi proyecto

Siempre me funciona

Experimenté este error al ejecutar algunos procesos muy costosos para la memoria. Cuando el sistema comenzó a quedarse sin memoria, comencé a notar este tipo de error. Tuve que cambiar el algoritmo para hacer un mejor uso de la memoria RAM.

Hay que señalar que, si bien algunos hilos lanzaron esta excepción, otros lanzaron:

System.Data.SqlClient.SqlException (0x80131904): tiempo de espera de conexión caducado. El tiempo de espera transcurrido al intentar consumir el acuse de recibo previo al inicio de sesión. Esto podría deberse a que el apretón de manos antes del inicio de sesión falló o el servidor no pudo responder a tiempo. La duración que se gastó al intentar conectar con este servidor fue: [Inicialización previa al inicio] = 43606; apretón de manos = 560; —> System.ComponentModel.Win32Exception (0x80004005): se agotó el tiempo de espera de la operación de espera

Ambos problemas desaparecieron después de que se cambió el sistema para que se pudiera ejecutar utilizando menos RAM.

Ejecutar el siguiente comando funcionó para mí:

netsh Winsock reset 

Visto en https://serverfault.com/a/487139/250527

Es posible que desee verificar algunas cosas:

  1. Tu servidor de producción permite conexiones remotas. (Posible que alguien apague esto, especialmente si tiene un DBA)

  2. Verifique su cadena de conexión. Algunas veces, si está usando una dirección IP o un nombre de servidor, esto causará este error. Prueba ambos.

Tuve el mismo problema, estaba almacenando datos de sesión en la base de datos, la cadena de conexión tenía Cifrado = Verdadero , lo que supongo que le dijo al cliente sql que se conectara al servidor en modo seguro (SSL), ¡y esto ayudó a eliminarlo!

Como se describe en la respuesta de Ricardo ,

 netsh Winsock reset 

me ha funcionado,

PD: si tiene instalado un administrador de descargas de Internet o progtwigs que cambian su Configuración de IP luego de ejecutar este comando cuando reinicia su computadora, IDM le preguntará si desea cambiar la configuración, establecer NO en este caso y luego ejecutar su aplicación, funcionará correctamente.

Espero que

Tuve un problema similar en el que no pude conectarme a una base de datos y probé las recomendaciones aquí.

Al final del día, esto es lo que funcionó para mí:

Se utilizó la herramienta Administrador de configuración del servidor SQL para habilitar los protocolos TCP / IP y / o Canalizaciones con nombre en la computadora cliente SQL Server.

  1. Haga clic en Inicio, señale Todos los progtwigs y haga clic en Administrador de configuración de SQL Server.
  2. Haga clic para expandir la Configuración de red de SQL Server y luego haga clic en Protocolos de cliente.
  3. Haga clic con el botón derecho en el protocolo TCP / IP y luego haga clic en Habilitar.
  4. Haga clic con el botón derecho en el protocolo Named Pipes y luego haga clic en Habilitar.
  5. Reinicie el servicio del servidor SQL si se le solicita que lo haga.

Todavía no estoy seguro de por qué o cuándo fue deshabilitado.

Para mí, la solución es eliminar los procesos zombie IIS express worker.

por ejemplo, localizar en el Administrador de tareas y finalizar la tarea.

enter image description here

Tuve el mismo problema y no tuve suerte con las soluciones sugeridas. Luego me encontré con este artículo y vi el comentario de Mirrh sobre un progtwig llamado Sendori bloqueando el LSP. No tengo idea de cómo llegó a mi computadora pero allí estaba y eliminarlo solucionó el problema.

Si el artículo no funciona, solo revisa tus Progtwigs y desinstala Sendori si lo ves.

En mi caso fue:

Persist Security Info=True;

en mi cadena de conexión que necesitaba ser eliminada. Una vez que hice eso, ya no tuve problemas.

Reinicié el servicio de SQL Server (Sharepoint) y resolvió el problema.

Obtuve exactamente el mismo problema sin cambios en la base de código o servidores. Resultó ser que el servidor de bases de datos se estaba ejecutando al 100% de la CPU y SQL Server estaba siendo privado de cualquier tiempo de CPU, lo que causó el tiempo de espera.

Tenía el mismo problema, la razón era la biblioteca BCrypt.Net, comstackda con el framework .NET 2.0, mientras que todo el proyecto, que la usaba, comstackba con .NET 4.0. Si los síntomas son los mismos, intente descargar el código fuente de BCrypt y reconstruirlo en la configuración de lanzamiento dentro de .NET 4.0. Después de que lo había hecho, “pre-login handshake” funcionó bien. Espero que ayude a cualquiera.