Windows Server 2025 / Diagnosticar eventos y fallos de servicios

Para diagnosticar un fallo del servidor, relacione el síntoma del usuario y su hora con los eventos pertinentes y el estado del servicio. Un identificador de evento aislado o una lista de servicios detenidos no establece la causa: compare con el funcionamiento habitual antes de cambiar ajustes.

Registre síntoma, hora y cambios recientes

Si falla un recurso compartido, anote cliente, cuenta, ruta exacta, mensaje de error y hora. Compruebe si afecta a todos los usuarios o solo a una identidad, y si fallan otros servicios del mismo equipo. Registre actualizaciones o cambios recientes sin asumir que son la causa. Ejecute estas consultas en el servidor investigado, por ejemplo FS1, con Windows PowerShell; no en su equipo de administración por error:

hostname
Get-Date
Get-TimeZone
Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime

hostname identifica el equipo de esta consola; Get-Date y Get-TimeZone permiten interpretar su reloj y zona, y LastBootUpTime indica el último inicio del sistema. Alinee la hora del usuario con la de los eventos, especialmente si compara registros de varios equipos; no cambie el reloj como primer paso. En una consola remota confirme también el equipo seleccionado en cada herramienta. Una advertencia única durante el arranque no equivale a un fallo repetido en el momento del incidente.

Limite el intervalo en el Visor de eventos

1. Abra eventvwr.msc y confirme el servidor del árbol. Revise Registros de Windows → Sistema y Aplicación según el síntoma.
2. Seleccione el registro y filtre alrededor de la hora del incidente, con margen antes y después. Elija niveles pertinentes sin excluir para siempre los eventos informativos del contexto.
3. Lea proveedor, identificador, hora y mensaje juntos. El mismo número de evento con otro proveedor puede tener otro significado; abra también Detalles para conservar los datos específicos.
4. Para el rol afectado, revise Registros de aplicaciones y servicios → Microsoft → Windows y los canales pertinentes. El Sistema de nombres de dominio (DNS), GroupPolicy para directivas de grupo y SMBServer para archivos compartidos son ejemplos; el canal exacto depende del componente instalado.
5. Compare los eventos anteriores y posteriores al fallo. Desde el panel de acciones guarde los eventos pertinentes en formato EVTX, el archivo de registro de eventos de Windows, conservando proveedor, equipo y periodo. No sustituya el original por una captura recortada.

El número de errores por sí solo no mide el impacto. Los eventos informativos pueden explicar el orden de inicio o una modificación, y pueden ser necesarios aunque primero filtre advertencias y errores. No borre registros para que desaparezcan avisos históricos: perdería el contexto sin resolver la causa. Para una denegación de acceso a archivos, distinga permisos y negociación siguiendo el diagnóstico de firma y cifrado SMB, el protocolo de Bloque de mensajes del servidor usado para compartir archivos.

Use consultas de PowerShell con límites

El siguiente ejemplo, en Windows PowerShell elevado del servidor, consulta como máximo los 50 eventos más recientes de nivel crítico, error o advertencia del registro System desde una hora antes de asignar el filtro. La referencia de filtrado de Get-WinEvent explica FilterHashtable. Aplique las condiciones al consultar, sin recuperar primero todos los registros del equipo:

$eventFilter = @{
    LogName = 'System'
    StartTime = (Get-Date).AddHours(-1)
    Level = 1,2,3
}
Get-WinEvent -FilterHashtable $eventFilter -MaxEvents 50 |
    Select-Object TimeCreated,ProviderName,Id,LevelDisplayName,Message

La salida muestra hora, proveedor, identificador, nivel y mensaje. Level=1,2,3 excluye eventos informativos; MaxEvents=50 puede dejar fuera el inicio del fallo si hay muchos registros dentro de esa hora. Adapte StartTime y, si necesita cerrar un intervalo, EndTime dentro de la tabla de filtro; amplíe o limite el periodo de forma deliberada. «No se encontraron eventos coincidentes» no prueba que el servicio de eventos falle. Distinga ese resultado de un acceso denegado o un nombre de registro incorrecto. Conserve el EVTX original; al exportar texto, preserve codificación y saltos de línea del mensaje, no solo lo que cabe en una tabla de consola.

Distinga estado, inicio y dependencias del servicio

Abra services.msc y busque el servicio concreto. En Propiedades revise estado, tipo de inicio, cuenta de inicio de sesión y pestaña de recuperación; anote los valores antes de intervenir. No inicie todos los servicios detenidos: algunos se ejecutan bajo demanda o por desencadenadores, y otros solo existen cuando está instalado un rol. Use su nombre interno, que puede diferir del nombre mostrado. Esta consulta usa W32Time, el servicio Hora de Windows, solo como ejemplo de lectura:

Get-Service -Name W32Time
Get-Service -Name W32Time -RequiredServices
Get-Service -Name W32Time -DependentServices
Get-CimInstance Win32_Service -Filter "Name='W32Time'" | Select-Object Name,State,StartMode,StartName

La clase Win32_Service distingue State, el estado actual, StartMode, el modo de inicio, y StartName, la cuenta que ejecuta el servicio; StartName no es el nombre del equipo ni revela su contraseña. Esta selección no muestra toda la configuración de inicio retrasado, desencadenadores o acciones de recuperación. Revise esos detalles donde corresponda antes de concluir que un servicio detenido debería estar siempre activo. Que W32Time responda a estas consultas tampoco diagnostica por sí solo toda la sincronización horaria del dominio.

Los comandos consultan W32Time sin iniciarlo ni modificarlo. RequiredServices devuelve servicios que W32Time necesita; DependentServices devuelve servicios que dependen de W32Time. Según la referencia de Get-Service, son direcciones distintas. Una lista vacía puede ser un resultado válido y no demuestra una avería. Compare Status con State de la consulta de configuración; Running indica proceso de servicio en ejecución, no que la función que usa el cliente esté sana.

Cambiar el tipo de inicio no equivale a iniciar o reiniciar una vez el servicio. Si se detiene enseguida, relacione la hora con eventos de cuenta, configuración, permisos o dependencias; no repita reinicios sin estudiar la causa. La pestaña Recuperación puede producir reintentos que alteren la secuencia observada. Una contraseña de servicio compartida puede usarse en otros equipos o tareas: restablecerla sin revisar consumidores puede ampliar el fallo. No utilice W32Time como experimento de parada en un dominio para demostrar estos conceptos.

Conserve pruebas antes de un cambio concreto

1. Guarde los registros y la configuración inicial del servicio, incluidos inicio, identidad y recuperación. Antes de compartirlos, revise nombres internos, rutas, cuentas y datos de mensajes; conserve el original protegido y prepare una copia depurada para terceros.
2. Defina qué hipótesis probará un inicio o reinicio, qué usuarios y servicios dependientes afectará y cuándo puede hacerlo. Si no tiene vía de recuperación o no conoce el alcance, continúe investigando antes de cambiar.
3. Aplique únicamente el cambio justificado al servicio relacionado. Compare su estado y los eventos del mismo intervalo; no cambie a la vez inicio, credenciales, dependencias y reglas de acceso.
4. Repita la operación original desde el mismo cliente y con la misma cuenta. Por ejemplo, vuelva a leer el mismo archivo compartido; que un servicio muestre Running no demuestra que ese acceso ya funcione.
5. Si la hipótesis no se confirma, revierta solo los valores que cambió y registró, y compruebe el efecto de la reversión. Delimite el siguiente paso con las pruebas nuevas, sin restablecer todas las opciones a supuestos valores predeterminados.

Modificar Administración remota de Windows (Windows Remote Management, WinRM) u otros servicios de acceso puede interrumpir su propia sesión. Disponga de consola antes de una intervención y confirme cómo volverá al estado anterior. No empiece borrando registros, reiniciando todos los servicios ni reiniciando el servidor. El criterio de cierre es repetir la operación que fallaba con el mismo cliente, identidad y ruta, observar el resultado esperado y revisar si reaparecen los eventos relacionados; una consola sin errores visibles no basta.