Cómo reparar servicios que no arrancan (Service Control Manager)

Cuando un servicio esencial de Windows no arranca y el Service Control Manager empieza a llenar el Visor de eventos de errores (7000, 7001, 7003, 7023, 1060, 1068, etc.), el sistema puede volverse casi inusable: sin red, sin sonido, sin Xbox, sin actualizaciones, sin inicio de sesión en dominio… y la sensación de que lo único que queda es formatear. La buena noticia es que Windows incluye herramientas muy potentes para diagnosticar y reparar estos problemas antes de llegar al desastre final de reinstalar todo.

En esta guía vas a ver, paso a paso y con todo lujo de detalles, cómo diagnosticar por qué un servicio no arranca (ya sea Netlogon, un servicio de Xbox, Workstation, etc.) y cómo usar correctamente SFC, DISM y CHKDSK para reparar archivos del sistema, la imagen de Windows y el propio disco. Además, revisaremos errores típicos del Administrador de control de servicios, cómo interpretar sus mensajes y qué hacer cuando ni siquiera estas herramientas son suficientes.

Qué es Service Control Manager y por qué fallan los servicios

En Windows, el Service Control Manager (SCM) es el componente responsable de gestionar el ciclo de vida de los servicios: los inicia, los detiene, controla sus dependencias y registra los errores cuando algo va mal. Cuando ves eventos como el 7000, 7001, 7003, 7023 o códigos de error tipo 1060, 1068, 13, etc., es el SCM quien los está dejando por escrito en el registro de eventos.

Un servicio puede no arrancar por mil motivos, pero los más habituales son dependencias mal configuradas, archivos corruptos o binarios/DLL que han desaparecido. A veces el problema parece pequeño (por ejemplo, no funciona la app de Xbox), pero detrás hay un servicio clave que Windows no es capaz de iniciar porque algo en la configuración o en los archivos del sistema está roto.

Los síntomas pueden ir desde cosas ligeras (una app concreta que falla) hasta fallos graves del sistema: servicios de red que no se inician, Windows Update muerto, imposibilidad de unirse al dominio, pérdida de sonido o pantallazos azules frecuentes. De ahí que sea clave entender qué está pasando realmente antes de tocar nada al azar.

Errores típicos de servicios que no arrancan (Service Control Manager)

Cuando un servicio peta, el Visor de eventos suele dar pistas bastante claras. Conviene acostumbrarse a revisar siempre el registro «Sistema» filtrando por origen «Service Control Manager». Estos son algunos errores clásicos y lo que significan en la práctica.

El evento 7000 indica que un servicio no se ha podido iniciar y normalmente acompaña un mensaje del estilo «El sistema no puede encontrar el archivo especificado» o «Acceso denegado». Aquí ya sabemos que o bien la ruta del ejecutable (ImagePath) está mal, o falta el archivo, o hay un problema de permisos.

El evento 7001 es muy habitual en problemas de dependencias: «El servicio X depende del servicio Y que no se pudo iniciar». Es la típica cascada en la que Workstation (LanmanWorkstation) no arranca porque otra dependencia está deshabilitada, y Netlogon tampoco se inicia porque depende de Workstation, y así sucesivamente.

El evento 7003 avisa de que se ha definido una dependencia que no existe: «El servicio Netlogon depende del siguiente servicio: Contoso_Service. Es posible que este servicio no esté instalado». Dicho de otro modo, en el registro hay un nombre de servicio en la clave DependsOnService que ya no corresponde a ningún servicio real.

El evento 7023 suele acompañar a un servicio que se cierra inmediatamente tras intentar arrancar, devolviendo un código de error (por ejemplo el 1060, servicio inexistente). Esto se ve mucho cuando algún componente del sistema se ha dañado y el servicio termina de forma inesperada.

Ejemplos reales: servicios de Xbox y errores de Netlogon

Para aterrizar todo esto, piensa en dos casos muy frecuentes: los servicios de Xbox en Windows 10/11 y el clásico servicio Netlogon en equipos unidos a un dominio.

En el primer caso, un usuario intenta usar la app de Xbox y, de repente, la ventana de inicio de sesión se abre y se cierra sola. Mirando servicios, ve que «Xbox Live Auth Manager» no arranca y lanza «Error 13: Los datos no son válidos». Otro servicio, «Xbox Live Game Save», devuelve «Error 1068: el servicio o grupo de dependencias no pudo iniciarse», porque depende del primero. «Xbox Live Networking Service» sí funciona. Resultado: todo apunta a que los datos de configuración o archivos del servicio principal están corruptos.

En el caso de Netlogon en un entorno de dominio, los fallos son todavía más delicados. Netlogon es el servicio que gestiona las operaciones de inicio de sesión de dominio, NTLM, Kerberos (PAC), detección de controladores de dominio (DC) y mantenimiento de contraseñas de cuentas de equipo. Si este servicio no arranca, se rompen cosas como:

• Inicio de sesión en dominio y establecimiento de sesiones seguras con controladores de dominio.
• Compartición de recursos SYSVOL y NETLOGON en controladores de dominio.
• Actualización de registros DNS SRV necesarios para que los clientes localicen un DC.
• Relaciones de confianza entre dominios y sincronización de hora con W32Time.

Cuando Netlogon no se inicia por dependencias en mal estado (por ejemplo, Workstation o Server fallando), el registro de eventos muestra errores 7001 en cadena, y otros servicios como W32Time o el servicio de directiva de grupo empiezan a registrar advertencias (por ejemplo, los eventos 159, 130, 1110) porque no pueden hablar con Netlogon o con un DC.

Cómo funcionan las dependencias de servicios en Windows

Todo esto se complica porque los servicios de Windows no están aislados, se apoyan unos en otros. Esa relación se llama «dependencia» y se gestiona desde el propio Service Control Manager.

Si entras en services.msc, botón derecho en un servicio, Propiedades, pestaña «Dependencias», verás una especie de árbol que muestra de qué servicios depende ese servicio y qué otros dependen de él. Por ejemplo, Netlogon en un controlador de dominio depende de LanmanWorkstation y LanmanServer, y esos a su vez dependen de otros componentes como el explorador, SRV2, SRVNET, NSI, etc.

Esta información no es magia: está almacenada en el registro, en HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NombreDelServicio. Dentro de cada clave de servicio existe un valor DependsOnService con la lista de servicios que deben estar activos antes de que este pueda iniciarse.

Puedes consultar la configuración también por consola con la utilidad sc.exe. El comando sc qc netlogon te devuelve, entre otros datos, el binario del servicio, el tipo de inicio y las dependencias (por ejemplo, «DEPENDENCIES : LanmanWorkstation : LanmanServer»). Esto es muy útil para comprobar si alguien ha tocado donde no debía.

Cuando un servicio dependiente no arranca, todos los servicios que dependen de él fallan en cascada. Por eso es tan importante identificar cuál es el primer servicio de la cadena que no arranca, en lugar de quedarse solo con el que te interesa (Netlogon, Xbox, etc.).

Causas frecuentes: archivos corruptos y errores de configuración

Muchos de los problemas de servicios que no arrancan tienen un denominador común: corrupción en archivos del sistema o en el propio registro. Y esa corrupción no aparece por arte de magia; normalmente la provocan situaciones muy concretas.

Una causa típica son los apagados bruscos, tirones de corriente o reinicios forzados mientras Windows está escribiendo en el disco. Si en ese momento se estaban tocando archivos críticos del sistema o DLL compartidas, pueden quedar en un estado inconsistente. Cuando el servicio vuelve a cargarlos, se encuentra con un archivo dañado.

Otra fuente clásica de problemas son las actualizaciones de Windows que fallan a medias: un corte de luz, problemas de red, conflictos con drivers o con software de seguridad… El resultado es que algunos componentes se han actualizado y otros no, creando un puzzle imposible. De ahí que después de ciertas actualizaciones problemáticas se vean oleadas de errores 7000, 7023 o pantallazos azules.

No hay que olvidar tampoco el malware. Virus, troyanos y otras «alegrías» pueden modificar, borrar o sustituir DLL y ejecutables de Windows. A veces lo hacen de forma deliberada para persistir en el sistema, otras simplemente rompen cosas colateralmente. En ambos casos, acabas con servicios que no arrancan porque el ejecutable o una librería vinculada han dejado de ser fiables.

Finalmente, están los fallos de hardware: sectores dañados, discos moribundos, SSD con errores. Si las zonas del disco donde residen ficheros de sistema o hives del registro empiezan a fallar, verás síntomas como lentitud extrema, cuelgues aleatorios y errores recurrentes de servicios. CHKDSK suele ser el canario en la mina para este tipo de problemas.

Herramientas clave: SFC, DISM y CHKDSK (y en qué se diferencian)

Windows trae de serie tres utilidades de consola que son la navaja suiza para reparar servicios que no arrancan por corrupción del sistema. No tienen interfaz bonita, pero hacen el trabajo mejor que la mayoría de programas de terceros.

El Comprobador de archivos de sistema, SFC (System File Checker), se dedica a analizar todos los archivos protegidos de Windows y comparar su integridad con una copia de confianza almacenada en la memoria caché de Windows File Protection (WFP). Si detecta un archivo alterado o inexistente, lo reemplaza automáticamente desde esa caché.

DISM (Deployment Image Servicing and Management) juega en otra liga: trabaja con la imagen completa de Windows (el «esqueleto» del sistema). Compara el estado actual del sistema con una imagen limpia (local o en línea) y, si ve diferencias por corrupción, descarga o toma de la fuente correcta los archivos necesarios y los restaura.

CHKDSK (Check Disk), por su parte, no toca directamente los archivos de sistema, sino que revisa el estado del sistema de archivos y los sectores físicos del disco. Detecta errores lógicos en la estructura NTFS/FAT y sectores defectuosos, e intenta marcar los dañados y recuperar la información que sea posible.

De forma muy resumida: SFC repara archivos del sistema, DISM repara la imagen de Windows y CHKDSK repara el disco. Saber cuándo usar cada uno (y en qué orden) marca la diferencia entre recuperar el equipo o estar todo el día dando palos de ciego.

Cómo usar SFC /scannow para reparar archivos del sistema

El comando SFC es la primera herramienta a la que conviene recurrir cuando sospechas que algún componente de Windows está roto: servicios que no inician, errores «archivo no encontrado» al ejecutar tareas básicas o mensajes continuos de protección de recursos de Windows.

Para ejecutarlo en Windows 7, 8, 8.1, 10 u 11, basta con abrir CMD o PowerShell como administrador (buscar «cmd» o «powershell» en Inicio, clic derecho, «Ejecutar como administrador») y lanzar:

sfc /scannow

Este comando recorre todos los archivos de sistema protegidos, los compara con la copia de confianza en %WinDir%\System32\dllcache y reemplaza automáticamente cualquier archivo corrupto. Según la situación pueden aparecer varios mensajes al finalizar:

• «Protección de recursos de Windows no encontró ninguna infracción de integridad»: los archivos del sistema están bien; el problema seguramente está en otro sitio (drivers, software de terceros, hardware…).
• «Protección de recursos de Windows encontró archivos dañados y los reparó correctamente»: perfecto, se han reparado las corrupciones detectadas y en principio no hay que hacer nada más, salvo reiniciar y comprobar si los servicios ya arrancan.
• «Protección de recursos de Windows encontró archivos dañados y no pudo corregir algunos de ellos»: mala señal, la caché desde la que SFC intenta restaurar los archivos también está dañada. Aquí entra en juego DISM.
• «Protección de recursos de Windows no pudo realizar la operación solicitada»: SFC no ha podido completar el análisis, normalmente por conflictos o bloqueos. Suele recomendarse repetirlo en Modo seguro o después de haber pasado DISM.

Existe toda una familia de parámetros menos usados pero muy útiles: /verifyonly para comprobar sin reparar, /scanfile y /verifyfile para analizar archivos concretos, /offbootdir y /offwindir para trabajar con sistemas sin conexión (por ejemplo, desde un medio de recuperación). Incluso puedes personalizar el archivo de log con /offlogfile.

En situaciones extremas en las que Windows no arranca ni en Modo seguro, puedes lanzar SFC desde un medio de instalación o recuperación. Arrancas desde el USB/DVD, eliges «Reparar el equipo» y abres el símbolo del sistema. Desde ahí ejecutas algo como:

sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows

Adaptando C: a la letra de la unidad donde esté la instalación de Windows montada en ese entorno. Esto permite reparar archivos del sistema sin necesidad de iniciar el escritorio, algo clave cuando los servicios críticos ni siquiera permiten llegar a la pantalla de inicio de sesión.

Cómo usar DISM /RestoreHealth para reparar la imagen de Windows

Cuando SFC no puede con todo, la siguiente herramienta de la lista es DISM. Es especialmente útil en Windows 8, 8.1, 10 y 11 cuando la memoria caché de archivos de sistema está dañada y SFC ya no tiene de dónde tirar para restaurar los ficheros correctos.

DISM puede trabajar con varios niveles de profundidad. Los parámetros más relevantes son /checkhealth, /scanhealth y /restorehealth, y conviene entender qué hace cada uno para no perder tiempo ni liarla.

El parámetro /checkhealth se limita a verificar si ya hay daños registrados en la imagen de Windows. Es rápido y no realiza un escaneo completo, simplemente comprueba si se sabe que la imagen está marcada como corrupta.

Con /scanhealth se da un paso más: se hace un análisis bastante profundo de la imagen actual buscando incoherencias. Esto sí puede tardar unos cuantos minutos, porque compara multitud de componentes con su estado esperado. Registra los problemas detectados, pero todavía no los corrige.

Finalmente, /restorehealth es el comando «gordo»: analiza y además repara la imagen usando como referencia una copia limpia (local o, por defecto, a través de Windows Update). Este es el que debes ejecutar cuando sospechas daños en componentes que SFC no arregla.

El uso práctico es sencillo. De nuevo, abre CMD o PowerShell como administrador y ejecuta:

DISM /Online /Cleanup-Image /RestoreHealth

El parámetro /Online indica que vas a trabajar sobre el sistema en ejecución, y /Cleanup-Image ordena que se revisen y reparen componentes de la imagen actual. El proceso puede tardar bastante, especialmente si tiene que descargar archivos desde Windows Update. Lo ideal es dejarlo terminar sin tocar nada, aunque tarde una hora o más.

Si por lo que sea Windows Update no funciona, o el equipo no tiene acceso a Internet, puedes proporcionar una fuente alternativa de archivos limpios, por ejemplo otra instalación sana de Windows o la propia ISO montada. El comando sería algo del estilo:

DISM /Online /Cleanup-Image /RestoreHealth /Source:C:\RepairSource\Windows /LimitAccess

Donde C:\RepairSource\Windows apunta a la ruta que contiene la carpeta «Windows» de la imagen de referencia (puede ser una unidad USB, un recurso compartido de red, etc.). El parámetro /LimitAccess evita que DISM intente contactar con Windows Update, usando solo la fuente indicada.

En Windows 7 no existe DISM con estas capacidades. En su lugar, Microsoft proporcionó la System Update Readiness Tool (SURT), descargable desde el Catálogo de Microsoft Update. Su misión es similar: analizar el sistema y reparar incoherencias de componentes que SFC no consigue resolver.

Cómo usar CHKDSK /F /R para detectar fallos en el disco

Si tras pasar SFC y DISM sigues con errores aleatorios, pantallazos azules, lentitud extrema al arrancar y servicios que fallan sin motivo aparente, es hora de sospechar del disco. Ahí entra en juego CHKDSK.

CHKDSK es un veterano del ecosistema Windows que se encarga de analizar la estructura del sistema de archivos y los sectores físicos del disco. Trabaja con unidades NTFS, FAT y FAT32, y es capaz de corregir errores lógicos (entradas de directorio inconsistentes, índices corruptos, descriptores de seguridad dañados) y marcar sectores defectuosos para que el sistema no los use.

Un comando típico para revisar la unidad del sistema sería:

chkdsk C: /F /R

Aquí, C: es la letra de la unidad a revisar; /F indica que quieres corregir automáticamente los errores encontrados, y /R que se escaneen los sectores defectuosos e intente recuperar los datos legibles. Si intentas hacerlo sobre la unidad donde está instalado Windows, lo normal es que el sistema te diga que no puede bloquearla ahora y te ofrezca programar la comprobación para el próximo reinicio. Aceptas, reinicias, y dejas que trabaje.

Para NTFS hay parámetros adicionales muy interesantes: /scan para un escaneo en línea, /spotfix para corregir puntos concretos sin un análisis completo, /perf para usar más recursos y acelerar el proceso, o /sdcleanup para limpiar entradas de seguridad innecesarias. No son imprescindibles para el usuario medio, pero pueden ayudar en ciertos escenarios.

Es importante entender que, aunque CHKDSK no está diseñado para borrar datos personales, al marcar sectores como dañados es posible que parte de la información almacenada en esas zonas se pierda. Por eso siempre se recomienda tener una copia de seguridad previa si sospechas que el disco «está tocado».

En qué orden ejecutar DISM, SFC y CHKDSK

Una duda recurrente es el orden correcto de estas herramientas. Aunque hay partidarios de varias secuencias, un enfoque muy sensato cuando los servicios no arrancan por posibles corrupciones es empezar por la imagen, seguir con los archivos del sistema y terminar con el disco.

En la práctica, un flujo de trabajo razonable sería:

• Ejecutar primero DISM /Online /Cleanup-Image /RestoreHealth para asegurarte de que la imagen de Windows está limpia y que SFC tendrá una fuente fiable de archivos con la que trabajar.
• Después, lanzar sfc /scannow para que repare todos los archivos protegidos del sistema que encuentre dañados apoyándose ya en esa imagen corregida.
• Si pese a todo sigues con síntomas raros (lentitud extrema, pantallazos, servicios que vuelven a corromperse), ejecutar chkdsk /F /R sobre la unidad del sistema y, si procede, sobre otras unidades de datos.

Este enfoque tiene la ventaja de que evita que SFC intente reparar archivos usando una caché corrupta, y asegura que cualquier corrupción a nivel de imagen se solucione antes de entrar en detalles. Además, si al final resulta que el disco tiene sectores defectuosos, lo habrás detectado y podrás plantearte un cambio de unidad antes de que el problema vaya a más.

Cuándo no queda otra que reinstalar Windows

Por muy potentes que sean SFC, DISM y CHKDSK, hay casos en los que el sistema está tan tocado que no merece la pena seguir parcheando. Algunos indicios claros de que ha llegado el momento de plantear una reinstalación son los siguientes.

Si tras repetir varias veces los comandos (incluyendo ejecución en Modo seguro o desde medios de recuperación) los errores persisten o vuelven a los pocos días, es muy probable que haya daños más profundos o conflictos de software difíciles de aislar.

En presencia de infecciones de malware serias que han manipulado servicios, DLL del sistema y configuraciones críticas, aunque logres limpiar el equipo a medias, lo normal es que queden restos que sigan causando inestabilidad. En ese caso, una instalación limpia es a menudo la opción más segura.

Cuando el equipo muestra problemas graves de rendimiento, bloqueos constantes, reinicios aleatorios y comportamientos erráticos que no mejoran tras pasar herramientas de reparación, tiene sentido dejar de perder horas y empezar de cero con una instalación limpia, siempre manteniendo copia de tus documentos.

También es bastante recomendable reinstalar si has hecho cambios fuertes de hardware (placa base, almacenamiento principal, etc.), porque aunque Windows suele adaptarse, la acumulación de drivers antiguos y configuraciones previas puede ser una fuente de errores de servicios y dispositivos.

Y por supuesto, cuando una actualización mayor de Windows queda a medias y deja el sistema en un estado semi-funcional del que no sales ni con DISM ni con SFC, reinstalar suele dar mejores resultados que intentar «deshacer» chapuzas de actualización.

Preguntas frecuentes rápidas

Muchas dudas se repiten una y otra vez cuando hablamos de reparar servicios que no arrancan usando estas utilidades. Conviene dejar claras algunas de las más comunes para evitar sustos.

Una de ellas es si es seguro ejecutar SFC, DISM y CHKDSK. La respuesta es que sí, siempre que los lances con permisos de administrador y no interrumpas el proceso a las bravas (sobre todo en CHKDSK). Son herramientas oficiales de Microsoft pensadas precisamente para esto.

Otra cuestión habitual es qué comando usar primero, SFC o DISM. Si el problema parece menor (por ejemplo, una funcionalidad que falla pero el sistema está razonablemente estable), puedes empezar por SFC y, si no arregla todo, pasar a DISM. Si los síntomas son más serios o ya sabes que hay corrupción fuerte (mensajes de SFC indicando que no puede reparar archivos), es mejor empezar por DISM.

También preocupa si estos comandos pueden borrar archivos personales. Ni SFC ni DISM están diseñados para tocar documentos, fotos o datos de usuario. CHKDSK tampoco los elimina como tal, pero si esos datos están almacenados en sectores físicamente dañados que deban marcarse como inutilizables, podrías perder parte de ellos. De ahí que siempre sea buena idea tener copias de seguridad actualizadas.

Por último, muchos se preguntan si hace falta ser «usuario avanzado» para usar estas herramientas. La realidad es que, siguiendo pasos claros y sin prisa, cualquier usuario medio puede ejecutarlas sin mayor complicación. Lo que sí conviene es entender qué hace cada una para no lanzar comandos al azar y luego no saber qué ha pasado.

Cuando un servicio de Windows se niega a arrancar, el Service Control Manager te deja un rastro bastante claro en el Visor de eventos y el propio sistema te da munición de sobra para pelear: desde revisar dependencias en services.msc o en el registro hasta tirar de SFC, DISM y CHKDSK en el orden adecuado. Combinando todo ello, en la mayoría de casos podrás recuperar servicios críticos como Netlogon, Workstation, los componentes de Xbox o Windows Update sin formatear; y si ni aun así lo consigues, al menos tendrás claro que ha llegado el momento de una reinstalación limpia y no seguirás perdiendo tiempo a ciegas.