Tras actualizar a SQL Server 2022, algunos administradores encuentran que el servicio se inicia y se detiene de inmediato, arrojando errores de “no se pudo abrir el puerto” a pesar de que TCP/IP está habilitado y el firewall parece inofensivo. Este artículo detalla las causas habituales y explica paso a paso cómo volver a tener una instancia estable.
Por qué SQL Server deja de escuchar en su puerto
Una instancia del Motor de Base de Datos depende de que el proceso sqlservr.exe
pueda vincularse al puerto asignado (por defecto 1433 o uno dinámico). Cuando la reserva falla o se interrumpe durante el arranque, el servicio se detiene para evitar corrupción y rechazos intermitentes. Los motivos más comunes son:
- Otro proceso ya vinculado al mismo puerto.
- Filtros de seguridad (antivirus, EDR, firewall de terceros) que inyectan bibliotecas y bloquean bind().
- Rangos de puertos reservados por directiva GPO (
ReservedPorts
). - Permisos insuficientes de la cuenta de servicio para “Escuchar en el puerto TCP”.
- Cambios de NIC o de IP después de la migración que invalidan la configuración guardada en registry.
- Errores introducidos por parches de sistema o de CU antiguas corregidas en builds posteriores.
Metodología de diagnóstico recomendada
Revisar la configuración de red en SQL Server Configuration Manager
Asegúrate de que solo los protocolos necesarios estén habilitados. Desactiva Named Pipes si toda tu aplicación habla por TCP/IP e inspecciona la pestaña “Direcciones IP”:
- Localiza la IP que verdaderamente corresponde a la interfaz del servidor.
- Configura “Puerto TCP” con el número deseado (1433 para estático) o pon “0” en “TCP Dynamic Ports” para decirle a SQL Server que use uno fijo.
- Deshabilita la columna “Enabled” en cualquier IP que no utilices, incluidas las de
127.0.0.1
si no requieres loopback.
Confirmar que ningún proceso robe el puerto
netstat -an | find ":1433"
Si ves un estado LISTENING
antes de arrancar el servicio, otra aplicación —o incluso otra instancia de SQL emparentada— ocupa la dirección. Cambia su puerto o deténla mientras pruebas.
Corroborar los servicios auxiliares
El servicio SQL Browser es necesario únicamente cuando:
- Usas instancias con puertos dinámicos.
- Usas alias o nombres de instancia y el cliente necesita resolver el puerto redireccionado.
Si trabajas con un puerto estático fijo y ninguna instancia con nombre, SQL Browser puede permanecer detenido para reducir superficie de ataque.
Interpretar el Error Log
Durante cada intento de arranque, la primera línea crítica suele lucir así:
Server TCP provider failed to listen on [ IP ]:1433. Error: 0x271D.
Error 0x271D = 10013 (WSAEACCES: Acceso denegado)
Código WinSock | Descripción | Causa típica |
---|---|---|
0x0000 (0) | Operación completada | Mensaje genérico que, irónicamente, precede a la caída; indica que el bind devolvió error sin contexto adicional. |
0x0002 (2) | El sistema no puede encontrar el archivo | Señal de que la dirección IP especificada no existe o no está levantada. |
0x271D (10013) | Permiso denegado | Barreras de seguridad, puertos reservados, privilegio faltante. |
0x2740 (10048) | La dirección ya se encuentra en uso | Otro proceso ocupa el puerto. |
Validar políticas de grupo y software de seguridad
Aunque desactives el Firewall de Windows, políticas de dominio pueden reactivar reglas o cargar filtros de manera asíncrona. Verifica:
- Directivas de exclusión en Endpoint Detection & Response.
- Reglas en “Computer Configuration > Administrative Templates > Network > Windows Defender Firewall > WFAS”.
- Listas de puertos reservados:
netsh int ipv4 show excludedportrange protocol=tcp
.
Si el rango incluye 1433, elimina la reserva o mueve la instancia a un puerto libre.
Comprobaciones de permisos de la cuenta de servicio
Una cuenta Enterprise Admin contiene privilegios de red de manera predeterminada, pero no garantiza:
- “Log on as a service” en la GPO local.
- Permiso de
SeImpersonatePrivilege
cuando un agente terceros ha endurecido el servidor.
Otorga explícitamente derechos con gpedit.msc
, reinicia la máquina y vuelve a probar.
Pruebas de conectividad locales y remotas
Una vez que el servicio inicie sin errores, verifica la escucha:
Test-NetConnection -ComputerName 127.0.0.1 -Port 1433
Repite desde un cliente en la misma subred. Si falla externamente pero no localmente, la causa es la red intermedia, casi siempre la VLAN o ACL del switch.
Impacto de las Cumulative Updates
Desde el lanzamiento RTM de SQL Server 2022, varias CUs corrigieron problemas de canal de transporte y compatibilidad con ciertos drivers de red virtual. Aplica siempre la CU más reciente antes de abrir un ticket. Además de arreglos de escucha, obtendrás mejoras de rendimiento en TempDB y optimización de cardinalidad.
Cuándo aumentar ConnectRetryCount
y por qué no es una cura
Las bibliotecas cliente de .NET Core implementan reconexión automática (por defecto 3 intentos). Elevar la cifra solo reduce la probabilidad de que una caída ocasional llegue a la aplicación, pero no evita que el motor se detenga. Úsalo como contingencia, no como solución.
Plan de acción antes de escalar al soporte de Microsoft
- Reproduce el fallo con
sqlservr.exe -s <Instancia> -c -m
en modo consola para ver la traza en tiempo real. - Guarda los archivos ERRORLOG, Application y System de los últimos dos arranques.
- Toma una captura de
netsh int ipv4 show excludedportrange
. - Ejecútalo de nuevo tras deshabilitar temporalmente el antivirus.
- Anota la versión exacta con
SELECT @@VERSION;
y el nivel de CU. - Abre un hilo en Microsoft Q&A etiquetado como “SQL Server” y adjunta esta información.
Cuantos más datos proporciones, más rápido el ingeniero podrá descartar causas y sugerir parches específicos.
Buenas prácticas para evitar futuras caídas
- Asigna puertos estáticos a todas las instancias productivas y documenta las reservas.
- Mantén un Configuration Baseline que incluya script de netsh para reabrir puertos tras un parche.
- Programa actualizaciones mensuales: primero SO, luego CU de SQL, finalmente actualizaciones del driver de red.
- Registra cambios de seguridad en un libro de bitácora DevSecOps; la mayoría de bloqueos provienen de nuevas reglas implementadas sin validación.
- Sobreinstala una instancia de prueba en la misma versión que producción para validar hotfixes.
Caso práctico: migración con éxito tras correcciones
En una empresa de retail se migró un ERP de SQL Server 2017 a 2022. Durante la ventana de mantenimiento:
- Se instaló SQL 2022 RTM sin CU.
- El servicio caía al instante con error
0x2740
. - Un endpoint security agent ocupaba 1433 para inspección SSL.
- Se reasignó la instancia a 1450, se actualizó a CU 10 y se añadió una exclusión de puerto.
Resultado: la instancia permanece estable; el equipo de seguridad mueve su agente a un puerto alto sin impacto en SQL.
Conclusión
Los cierres súbitos del servicio en SQL Server 2022 casi siempre se remontan a conflictos de red o seguridad. Antes de reinstalar el motor, verifica la configuración del puerto, las reservas del sistema y las políticas de protección. Con un diagnóstico ordenado y la CU correcta, tu instancia volverá a escuchar sin sorpresas.