Servicios Windows en Automático que no arrancan: auditoría del timeout del SCM

Un servicio configurado como Automático que no arranca tras un reinicio es uno de los fallos más difíciles de diagnosticar en Windows, porque el síntoma desaparece en cuanto lo inicias a mano. La causa suele estar en dependencias no satisfechas, cuentas con contraseñas expiradas o, como en el caso que analizamos aquí, en el timeout del Service Control Manager (SCM) durante el arranque.

Esta guía reproduce una auditoría real: dos servicios marcados como Automatic que aparecían Running bajo demanda, pero que fallaban sistemáticamente en cada reinicio.

Advertencia: modificar el registro (ServicesPipeTimeout) o las dependencias de servicios de sistema puede impedir el arranque de Windows. Exporta la clave antes de tocarla y ten a mano un punto de restauración o un medio de arranque de recuperación.

---

1. El síntoma: Running no significa arrancó solo

La primera comprobación confirma el estado actual, pero no dice nada sobre el arranque:

Get-Service -Name "MiServicioA" | Select-Object Name, Status, StartType

Name          Status StartType
----          ------ ---------
MiServicioA   Running Automatic

El servicio aparece Running y Automatic. El problema es intermitente o solo al arranque. La clave está en comparar la hora de arranque del sistema con la del proceso del servicio: si el proceso se inició varios minutos después, no arrancó solo.

---

2. Distinguir arranque automático de arranque manual

$svcs = "MiServicioA","MiServicioB"
$boot = (Get-CimInstance Win32_OperatingSystem).LastBootUpTime

foreach ($s in $svcs) {
    $w = Get-CimInstance Win32_Service -Filter "Name='$s'"
    $p = Get-Process -Id $w.ProcessId -ErrorAction SilentlyContinue

    [pscustomobject]@{
        Name         = $s
        State        = $w.State
        StartMode    = $w.StartMode
        StartName    = $w.StartName
        PID          = $w.ProcessId
        ProcessStart = $p.StartTime
        MinAfterBoot = if ($p.StartTime) { [math]::Round(($p.StartTime - $boot).TotalMinutes,1) } else { $null }
        PathName     = $w.PathName
        ExitCode     = $w.ExitCode
    }
} | Format-List

Valor de MinAfterBoot	Interpretación
0–2 minutos	Arrancó automáticamente con el sistema
Más de 5 minutos	Se inició después (manual o por recuperación)
null	El PID ya no existe: el servicio murió

---

3. Extraer los eventos del Service Control Manager

El Visor de Eventos es la fuente de evidencia principal. Estos son los IDs relevantes:

ID	Significado
7000	El servicio no pudo iniciarse
7009	Se agotó el timeout esperando la conexión con el servicio
7011	Timeout esperando una respuesta de transacción
7024	El servicio terminó con un error específico
7031	El servicio terminó inesperadamente
7034	El servicio terminó de forma inesperada (sin recuperación)
7036	Cambio de estado del servicio
7040	Cambió el tipo de inicio
7045	Se instaló un servicio nuevo

Get-WinEvent -FilterHashtable @{
    LogName='System'
    Id=7000,7009,7024,7031,7034,7036,7040,7045
    StartTime=(Get-Date).AddDays(-7)
} |
Where-Object { $_.Message -match 'MiServicioA|MiServicioB' } |
Select-Object TimeCreated, Id, LevelDisplayName, Message |
Sort-Object TimeCreated -Descending

---

4. El diagnóstico: timeout de 60 segundos

Los eventos del arranque delimitan el problema con precisión:

TimeCreated           Id LevelDisplayName Message
-----------           -- ---------------- -------
19/10/2026 17:36:47 7009 Error   Se agotó el tiempo de espera (60000 ms) para la conexión con el servicio MiServicioB.
19/10/2026 17:36:47 7000 Error   El servicio MiServicioB no pudo iniciarse debido al siguiente error: ...
19/10/2026 17:36:42 7009 Error   Se agotó el tiempo de espera (60000 ms) para la conexión con el servicio MiServicioA.
19/10/2026 17:36:42 7000 Error   El servicio MiServicioA no pudo iniciarse debido al siguiente error: ...

El arranque del sistema fue a las 17:35:09 y los errores aparecen ~90 segundos después. La interpretación es directa:

• 7009 indica que el SCM alcanzó el límite de 60000 ms esperando que el servicio reportara estado Running.
• 7000 es la consecuencia: el servicio no respondió a la solicitud de inicio en el tiempo previsto.

Que ocurra en ambos servicios apunta a una condición de carrera en el arranque: el sistema está lo bastante ocupado como para que los servicios no completen su inicialización dentro de la ventana que el SCM concede [1][2].

---

5. Comprobaciones previas antes de tocar el registro

Antes de aumentar timeouts, descarta las causas habituales. Cada comprobación es barata y elimina una hipótesis.

5.1 Dependencias

foreach ($s in "MiServicioA","MiServicioB") {
    Write-Host "===== $s ====="
    Get-Service -Name $s -RequiredServices | Select-Object Name,Status,StartType
    Get-Service -Name $s -DependentServices | Select-Object Name,Status,StartType
}

Todas las dependencias deben estar en Automatic y arrancar correctamente. Para forzar una dependencia explícita:

sc.exe config "MiServicioA" depend= RPCSS

Varias dependencias se separan con /: depend= RPCSS/Tcpip [3].

5.2 Cuenta de inicio y configuración real del servicio

foreach ($s in "MiServicioA","MiServicioB") {
    Write-Host "===== $s ====="
    Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\$s" |
        Select-Object PSChildName, Start, DelayedAutoStart, ImagePath, ObjectName, ErrorControl

    sc.exe qc "$s"
    sc.exe qfailure "$s"
    sc.exe enumdepend "$s"
}

Clave	Significado
Start = 2	Automático
Start = 3	Manual
DelayedAutoStart = 1	Automático (Inicio retrasado)
ObjectName	Cuenta con la que se ejecuta el servicio

Un error 1053 al iniciar apunta a permisos o a contraseña de la cuenta expirada.

---

6. Estrategias de solución

6.1 Aumentar el timeout del SCM (recomendada)

Es la solución documentada por Microsoft para eventos 7000, 7011 y 7009 [1]:

1. Abrir regedit.exe.
2. Navegar a HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control.
3. Localizar ServicesPipeTimeout. Si no existe, crear un valor DWORD (32 bits) con ese nombre.
4. Asignar valor decimal 120000 (2 minutos) o 180000 (3 minutos). La unidad son milisegundos.
5. Reiniciar el equipo.

Nota: ServicesPipeTimeout afecta a todos los servicios del sistema, no solo a los problemáticos. Aumentarlo da más margen al SCM, pero también retrasa la detección de fallos reales. Úsalo cuando hayas descartado dependencias y cuentas.

6.2 Inicio retrasado

Alternativa menos invasiva: retrasar el arranque para que el sistema tenga tiempo de estabilizarse.

Set-Service -Name "MiServicioA" -StartupType AutomaticDelayedStart
Set-Service -Name "MiServicioB" -StartupType AutomaticDelayedStart

Equivale a services.msc > Propiedades > Tipo de inicio > Automático (Inicio retrasado).

6.3 Configurar la recuperación ante fallos

sc.exe failure "MiServicioA" reset= 86400 actions= restart/60000/restart/60000/restart/60000

6.4 Optimizar el código del servicio (si es propio)

Si el servicio es de desarrollo propio, el problema real está en OnStart: reportar el estado Running cuanto antes y mover las tareas pesadas a un hilo secundario elimina el timeout de raíz [2].

---

7. Verificación tras el reinicio

1. Reiniciar Windows.
2. No iniciar el servicio a mano.
3. Ejecutar:

Get-Service -Name "MiServicioA","MiServicioB" | Select-Object Name, Status, StartType

4. Si están Stopped, consultar el estado detallado:

sc.exe queryex "MiServicioA"
sc.exe queryex "MiServicioB"

5. Repetir la extracción de eventos del punto 3 y confirmar que no aparecen nuevos 7000/7009 desde el arranque.

---

Conclusiones / En resumen

1. Running no implica arranque automático correcto: hay que comparar la hora del proceso con LastBootUpTime antes de dar el servicio por bueno.
2. Los eventos 7000 y 7009 juntos identifican un timeout del SCM, no un fallo del servicio en sí.
3. ServicesPipeTimeout es la solución documentada por Microsoft para este escenario, pero es global: descarta antes dependencias, cuentas y configuración de recuperación.
4. El Inicio retrasado es la alternativa prudente cuando el problema es la sobrecarga del arranque, y no requiere tocar el registro.
5. La causa raíz en servicios propios está casi siempre en OnStart: reportar Running tarde o bloquear el hilo principal garantiza el timeout.

---

📚 Fuentes consultadas

1. A service does not start, and events 7000, 7011, and 7009 are logged — Microsoft Learn
2. Windows service fails to start automatically after reboot — Microsoft Q&A
3. sc config — Microsoft Learn
4. Event ID 7000, 7011, 7009: a service does not start due to timeout — The Windows Club