A Windows Service is Down. Now What?

When a Windows service goes down, the investigation follows a standard five-step pattern. It is crucial not to restart the service immediately, as this may mask the underlying issue. Before taking any action, confirm the current state of the service. Use the command "Get-Service ServiceName" to check its status and start type.

For SQL Server, this might look like "Get-Service MSSQLSERVER, SQLSERVERAGENT, MsDtsServer130 | Select-Object Name, Status, StartType." If the service is already running and set to Automatic, the alert may not be actionable.

Next, map the service transitions using Event ID 7036 in the Windows logs. Pull the last 20 transitions and sort them chronologically to understand the precise sequence of stop-and-start events. Look for the last time the service went from running to stopped, and whether it recovered on its own. Multiple stop-start cycles may indicate a crash-and-restart loop.

Event IDs 1074, 6005, 6006, and 6008 provide clues about system-level triggers that could have caused the service to stop. Event 1074 indicates an intentional shutdown or restart, while Event 6005 shows the OS booting up, and Events 6006 and 6008 indicate the OS going down or shutting down unexpectedly.

Finally, read the application's own logs to understand why the service stopped. Every serious Windows service writes its own log. Common log locations include SQL Server, IIS, and services that write to the Windows Application log. For example, "Get-WinEvent -FilterHashtable @{ LogName = 'System'; Id = 7036 } | Where-Object { $_. Message -match 'SQL Server Agent (MSSQLSERVER)' } | Select-Object TimeCreated, Message" can be used to read the SQL Server logs.