Event Viewer is the built-in Microsoft Management Console snap-in for reading, filtering and managing Windows event logs, the structured records in which the operating system, services and applications report errors, warnings, security audits and routine activity. In Windows administration, it is the first place administrators look when they need to know what happened on a machine, when and why.
Event Viewer is opened with eventvwr.msc and works both on the local computer and on remote computers the administrator has rights to. It is only a viewer: the logs themselves are written by the Windows Event Log service in the binary EVTX format, and the same data can be queried from the command line or collected centrally.
How Windows event logging works
Components that want to log register as event providers. When something notable happens, a provider writes an event record to a channel, and the Windows Event Log service stores it in a log file under %SystemRoot%\System32\winevt\Logs. Each record has a fixed structure that makes filtering reliable across thousands of entries.
| Field | Meaning | Example |
|---|---|---|
| Event ID | Number identifying the event type within a provider | 4625 |
| Source or provider | Component that wrote the event | Microsoft-Windows-Security-Auditing |
| Level | Severity of the event | Error |
| Logged time | Timestamp of the event | Date and time to the millisecond |
| User and computer | Security context and host | SYSTEM on a named server |
| Event data | Provider-specific details in XML | Account name, logon type, failure code |
An event ID is only unique within its provider. Event ID 1000 from Application Error means an application crash, while the same number from another source can mean something unrelated, so administrators always read ID and source together.
Logs and event levels
Event Viewer groups logs into Windows Logs, the classic system-wide logs, and Applications and Services Logs, which hold hundreds of component-specific channels such as PowerShell, Task Scheduler or Windows Defender. Some analytic and debug channels are hidden and disabled by default because of their volume.
| Log | Content | Typical use |
|---|---|---|
| Application | Events from applications and some services | Crashes, database and backup errors |
| Security | Audit events defined by audit policy | Logons, privilege use, account changes |
| System | Events from drivers and Windows components | Startup, shutdown, service and disk issues |
| Setup | Installation and update events | Role installation and servicing problems |
| Forwarded Events | Events collected from other computers | Central monitoring with subscriptions |
Each event carries a level: Critical, Error, Warning, Information or Verbose. The Security log instead uses the keywords Audit Success and Audit Failure. Levels reflect the provider’s view, not the business impact, so a warning about a failing disk can matter far more than an error from a harmless helper process.
Event IDs every administrator should know
A small set of event IDs answers most everyday questions about reboots, logons and tampering. Knowing them turns Event Viewer from a wall of text into a targeted diagnostic tool.
| Event ID | Log | Meaning |
|---|---|---|
| 41 | System, Kernel-Power | System restarted without a clean shutdown |
| 1074 | System | Shutdown or restart initiated by a user or process |
| 6008 | System | Previous shutdown was unexpected |
| 7036 | System | A service entered the running or stopped state |
| 4624 and 4625 | Security | Successful and failed logon |
| 4740 | Security | User account locked out |
| 1102 | Security | Audit log was cleared |
Event ID 1102 deserves particular attention: clearing the Security log is a common attacker step to hide activity, and it should trigger an alert in any monitored environment.
Filtering, custom views and remote collection
The Filter Current Log dialog narrows a log by level, time range, source, event ID, keywords and user. For precise work, the XML tab accepts XPath queries against event data fields, for example selecting only failed logons for one account name. Filters can be saved as custom views, which also combine several logs into a single list.
- Attach a task to an event to run a script or program when a specific event appears.
- Use Save All Events As to export logs in EVTX, XML, CSV or text for analysis elsewhere.
- Query logs from scripts with Get-WinEvent in PowerShell or
wevtutilin the command prompt. - Collect events from many machines with Windows Event Forwarding subscriptions into the Forwarded Events log.
For more than a handful of servers, Event Viewer becomes a verification tool rather than a monitoring system. Organizations forward events to a central collector or a security information and event management platform, and use Event Viewer to inspect individual machines and confirm what the central system reports.
Log size, retention and common pitfalls
Each log has a maximum size and a retention policy, by default overwriting the oldest events when full. On a busy domain controller with detailed auditing, a Security log of default size can cover only hours of activity, which is too short for incident investigation. Sizes and retention are best set centrally with Group Policy.
| Pitfall | Consequence | Remedy |
|---|---|---|
| Default Security log size | Evidence overwritten before review | Enlarge the log and forward events |
| Auditing not configured | No logon or change events recorded | Enable advanced audit policy |
| Chasing every warning | Time lost on harmless noise | Correlate with symptoms and timestamps |
| Reading the ID without the source | Wrong diagnosis | Always check provider and ID together |
| Logs kept only locally | Attacker can clear them | Forward to a protected collector |
The idea in brief
Windows keeps a detailed diary of everything important that happens on a computer: programs that crash, services that start and stop, people who sign in and updates that install. Event Viewer is the program that lets you read that diary.
Most entries are harmless routine notes. The skill is knowing which pages to look at when something goes wrong, such as the entry that says the computer lost power or that someone typed the wrong password many times.
A practical scenario
A file server in a small accounting firm restarts unexpectedly twice in one week. The administrator opens Event Viewer on the server and filters the System log for event IDs 41, 1074 and 6008. No 1074 entry appears near the restart times, which rules out a planned reboot by a user or an update, while event 41 confirms that the system restarted without a clean shutdown.
Just before each crash, the System log shows repeated disk warnings from the storage controller driver. The administrator replaces the failing drive in the mirrored volume and then creates a custom view for disk and Kernel-Power events, with a task attached that emails the IT mailbox whenever one appears. Over the following month the server runs without further unplanned restarts, and the custom view becomes part of the weekly check routine.