Windows Event Log
Overview
The Error Log report covers SQL Server’s own log, but many root causes only show up in the Windows logs: disk and controller errors, storport resets, NTFS problems, cluster service events, low virtual memory, unexpected shutdowns and crashes of the SQL Server process.
The Windows Event Log report reads the System and Application logs of the host and shows:
- every Critical, Error and Warning event in the last 24 hours, 7 days or 30 days, plus the planned restarts (User32 1074) and boots (EventLog 6005) that explain a SQL Server restart,
- a category for each event: Storage, Cluster, Memory, Shutdown, SQL Service, Security or Other,
- a timeline with one lane per category and one for the SQL Server error log, on the same time axis, so a disk timeout and the 833 that followed it line up,
- a knowledge pane with what the picked event means and the next step.
Where to find it
| Route | How |
|---|---|
| Server tree | Right-click the server → Instance Level Reports → Windows Event Log |
| Instance reports navigator | Jobs and errors group |
| Related Links bar | From Error Log |
| Report arrows | Previous is What is Active, next is Workload by Application |
The toolbar
| Control | What it does |
|---|---|
| System and Application / System / Application | Which logs to read |
| 24 hours / 7 days / 30 days | How far back |
| SQL relevant only / All events | Hides the events that are not about SQL Server (on by default). Switching does not read the logs again |
| Error Log | Opens the SQL Server error log |
| Cancel | Stops a read in progress |
Which events are SQL relevant
An event is shown with SQL relevant only when it is:
- written by a SQL Server service (MSSQLSERVER, MSSQL$instance, the SQL Server Agent, Reporting Services, Full-Text, the Browser and the VSS writer),
- in the curated list below, or
- about SQL Server by its message (it names sqlservr.exe, MSSQL or SQL Server).
The curated list includes:
| Category | Events |
|---|---|
| Storage | disk 7, 11, 15, 51, 153, 157; storport 129 from any driver; Ntfs 50, 55, 98, 140; iScsiPrt 9, 20; mpio 16, 17 |
| Cluster | FailoverClustering 1069, 1126, 1129, 1135, 1146, 1177, 1205, 1230, 1254, 1564 |
| Memory | Resource-Exhaustion-Detector 2004; srv 2019, 2020 |
| Shutdown | EventLog 6008 (unexpected shutdown), Kernel-Power 41, bug check 1001, User32 1074, EventLog 6005 |
| SQL Service | Service Control Manager 7000, 7009, 7023, 7024, 7031, 7034, 7038 for a SQL Server service; Application Error 1000 and Windows Error Reporting 1001 for a SQL Server process |
| Security | Kerberos 4, KDC 11 (duplicate SPN), NETLOGON 5719, Schannel 36871, 36874, 36888 |
Events a SQL Server service writes are categorized by their SQL Server error number (823, 824, 825 and 833 are Storage, 701 and 17890 Memory, 18456 Security, 1480 and 19406 Cluster). SQL Server wraps some errors in event 18053 (“Error: 17300, Severity: 16”); the number inside is the one used.
Reading the page
The heading names the host (every node for a Failover Cluster Instance), when the logs were read, and the Windows account used for a remote read.
Notices in red say which log could not be read and how to fix it.
The timeline shows each event as a dot colored by level: dark red critical, red error, amber warning, blue information. The SQL Server error log lane shows fatal, error, warning and security lines from the error log over the same days. Hover a dot for its details; click it to select it in the grid and fill the knowledge pane. A dashed line marks the picked moment across every lane.
The grid lists the time (server time), host, log, level, source, event id, category and the first line of the message. Hover a row for the full message and the knowledge text; right-click to copy them. The grid exports to CSV and Excel like every other grid.
All times are held in UTC and shown on the server’s clock, so events from the workstation, the host and the SQL Server error log are ordered correctly even when they are in different time zones.
Permissions and setup
The event logs are read by Database Health Monitor from your workstation as your Windows user, not with the SQL Server login. For a host other than your own machine:
- your account must be in the host’s Event Log Readers group (or be an administrator there),
- the host’s Remote Event Log Management firewall rules must be enabled, for example
Enable-NetFirewallRule -DisplayGroup "Remote Event Log Management", - the Windows Event Log service must be running.
If a log is refused or the host cannot be reached, the page says so with these steps; nothing is raised as an error. For each log at most the newest 20,000 events are read, and the page says when a log held more.
The SQL Server error log lane needs permission to run xp_readerrorlog; without it the lane is empty and the page says why. The host name comes from SERVERPROPERTY('ComputerNamePhysicalNetBIOS') and, for a Failover Cluster Instance, sys.dm_os_cluster_nodes (which needs VIEW SERVER STATE).
SQL Server on Linux and Azure SQL have no Windows event log; the page says so.