Use Event Viewer to connect a Windows service failure with the errors recorded at the same time. The goal is to identify the failed component and a supported next action, rather than treating every warning on the server as the cause.
IN THIS ARTICLE
01 Collect the failure context
Record the service's display name and actual service name, the failed action, exact time and timezone. Note recent updates, credential changes, configuration edits and disk-space problems. If restarting the service would affect customers, assess that impact before retrying it.
02 Review the relevant events
- Open Event Viewer, or run
eventvwr.msc, using an account with access to the required logs. - Expand Windows Logs and open System. Filter the current log to a narrow period around the failure. Look for Service Control Manager and related dependency events.
- Read the complete event, including its provider, event ID, service name and error text. An event ID without its provider and context can be misleading.
- Check Application for the application's own error at the same time. Some products also use a dedicated channel under Applications and Services Logs.
- Compare events immediately before and after the failure. A dependent service, inaccessible file, rejected credential or database error may explain the later stop event.
- Save the relevant selected events or an appropriately scoped log export for the support record. Keep sensitive details restricted.
- Apply one evidence-based correction, then test the service and its actual application function. Review the new events to confirm whether the failure recurs.
03 Interpret dashboards carefully
Server Manager can collect and filter event and service information across servers. A dashboard's configured alert view is only a subset of the available evidence. Check the underlying event log when the summary does not explain the failure.
04 Example: correlate a failed Windows service with its event
Open PowerShell on the Windows Server using an account authorised to inspect its services and event logs. Replace ExampleService with the actual service name. This reads current status and recent Service Control Manager events without restarting anything.
Get-Service -Name 'ExampleService'
Get-WinEvent -FilterHashtable @{
LogName = 'System'
ProviderName = 'Service Control Manager'
StartTime = (Get-Date).AddMinutes(-30)
} -MaxEvents 30 | Select-Object TimeCreated, Id, LevelDisplayName, MessageRead the result: Match the service name and incident time in the event message. A stopped state may be expected for an on-demand service, while an unexpected exit or logon failure needs its specific error investigated. The latest event is not always the first cause in a chain of failures.
Check the application log and its own protected diagnostics for the same time. Preserve the relevant event identifiers before changing credentials, dependencies or recovery settings. A restart can restore availability temporarily while leaving the original failure unresolved.
Common questions
Does an error logged near the failure prove it caused the outage?
No. Correlate the resource, timing and failure mechanism. Some events describe a consequence, and unrelated background warnings can occur at the same time.
Should I clear the logs after fixing the service?
Preserve the incident evidence according to the retention process. Clearing logs is not a repair and can remove the comparison needed if the problem returns.