Windows Server 2025 / Diagnosticar logs de eventos e falhas de serviços
Para diagnosticar uma falha no servidor, relacione o sintoma informado pelo usuário e seu horário aos eventos relevantes e ao estado dos serviços. Um ID de evento isolado ou uma lista de serviços parados não prova a causa: compare com o funcionamento habitual antes de mudar a configuração.
Registre o sintoma, o horário e as mudanças recentes
Se o acesso a um compartilhamento falhar, anote o computador cliente, a conta, o caminho e a hora. Diferencie uma indisponibilidade geral da falha de um só serviço e identifique atualizações ou alterações recentes. Compare os horários no mesmo fuso e confirme qual servidor está examinando:
hostname
Get-Date
Get-TimeZone
Get-CimInstance Win32_OperatingSystem | Select-Object LastBootUpTime
Um console remoto pode mostrar vários servidores e levar a conclusões sobre a máquina errada. Diferencie avisos passageiros da inicialização de uma falha que se repete agora.
Limite o período no Visualizador de Eventos
- Abra eventvwr.msc e consulte Logs do Windows → Sistema e Aplicativo.
- Filtre o período próximo ao incidente e escolha os níveis de gravidade úteis.
- Leia provedor, ID, horário e mensagem em conjunto: o mesmo número pode significar algo diferente em outro provedor.
- Quando necessário, consulte Logs de Aplicativos e Serviços específicos da função, como DNS, GroupPolicy ou SMBServer.
- Compare os eventos próximos e preserve os arquivos EVTX originais.
A quantidade de erros, por si só, não mede o impacto sobre o serviço. Eventos informativos podem revelar a sequência de inicialização ou mudança; apagar erros antigos sem relação com o incidente não corrige a falha.
Use consultas limitadas do PowerShell
No PowerShell com direitos administrativos, este exemplo lê no máximo 50 eventos críticos, erros ou avisos recentes do log System. A filtragem de Get-WinEvent restringe os resultados já na coleta:
$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
A ausência de eventos correspondentes ao filtro não significa, por si só, que o serviço de eventos falhou. Confira período, nome do log e permissões de leitura. Ao exportar, preserve a codificação, as quebras de linha das mensagens e os logs originais.
Separe estado, tipo de inicialização e dependências do serviço
No services.msc, inspecione estado, tipo de inicialização, identidade de logon e comportamento de recuperação. Não inicie todos os serviços parados: alguns são acionados sob demanda ou não estão presentes sem um papel.
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
Esses comandos leem dados do serviço de Horário do Windows sem alterá-lo. RequiredServices são serviços de que W32Time precisa; DependentServices são os que dependem dele. Consulte a documentação de Get-Service para interpretar essas propriedades.
Mudar o tipo de inicialização é diferente de iniciar ou reiniciar uma vez. Um serviço que para imediatamente pode ter problema de conta, configuração, permissões ou dependências. Trocar a senha de uma conta de serviço compartilhada pode afetar outras aplicações.
Preserve evidências antes de fazer uma alteração direcionada
- Salve logs pertinentes e configurações originais do serviço, revisando informações internas antes de compartilhamento público.
- Estabeleça o propósito, impacto e tempo de manutenção de um reinício.
- Altere apenas o serviço relevante e compare estado e eventos.
- Repita a falha original do cliente nas mesmas condições.
- Se não for resolvido, restaure apenas as alterações registradas e restrinja a investigação.
Alterar WinRM ou outro serviço de acesso remoto pode encerrar sua sessão; mantenha acesso ao console. Não comece o diagnóstico apagando logs, reiniciando todos os serviços ou reiniciando o servidor.




