How to Check Shutdown History in Windows 11: Event Viewer to Automation

Every shutdown and restart your Windows 11 PC performs is recorded somewhere — and knowing where to look can turn an annoying mystery reboot into a solvable troubleshooting task or a clear audit trail. This article walks through every practical way to check shutdown history in Windows 11 — from the visual Event Viewer to command-line PowerShell, from quick exports to automated daily monitoring — and explains how to interpret the key Event IDs so you can separate clean shutdowns from crashes and power failures.

Background: why shutdown history matters​

Shutdown history is more than trivia for power users and administrators. Those timestamped entries in the Windows System log are the first place to look when a device restarts during an update, powers off unexpectedly, or behaves erratically. Reading these logs lets you:

• Audit who or what requested a shutdown or restart.
• Detect unexpected shutdowns that signal crashes, power loss, or hardware faults.
• Correlate restarts with updates, scheduled tasks, or driver failures.
• Create an evidence trail for shared or managed machines.

Windows writes discrete Event IDs to the System log for these occurrences. Understanding the high‑value IDs and where to find them converts raw log data into actionable insight.

---

Key Event IDs and what they mean​

Windows records shutdown‑related activity with a handful of widely used Event IDs. These are the ones to memorize and filter for when you’re checking shutdown history in Windows 11.

• Event ID 1074 — User/System initiated shutdown or restart. Shows the process or account that requested the shutdown and the (optional) reason text.
• Event ID 6006 — Event Log service stopped. Appears when the system shuts down cleanly.
• Event ID 6005 — Event Log service started. Commonly used as a proxy for boot/Startup time.
• Event ID 6008 — Unexpected shutdown. Logged when the previous shutdown was not clean.
• Event ID 41 (Kernel‑Power) — System rebooted without cleanly shutting down first. Often associated with hard power loss, crashes or hardware faults.

A typical clean shutdown cycle looks like: 1074 (shutdown initiated) → 6006 (event log stopped). A crash or power loss often surfaces as 41 or 6008 on the subsequent boot. These mappings are stable and form the basis for all the GUI and command-line filters shown below.

---

Overview: three practical approaches​

You can check shutdown history in three primary ways:

• The visual approach: Event Viewer (GUI), best for one-off investigations and context-rich inspection.
• The command-line approach: PowerShell (Get‑WinEvent / Get‑EventLog) and wevtutil, best for scripting, automation, and remote work.
• The quick/comfortable approach: third‑party utilities (e.g., NirSoft TurnedOnTimesView / LastActivityView) for instant tables and CSV exports.

Each method has strengths and tradeoffs; the rest of the article gives step‑by‑step instructions and recommended workflows.

---

Method 1 — Event Viewer (GUI): step-by-step​

Event Viewer is the built-in “flight recorder” for Windows. It’s perfect for users who prefer a visual interface and want to read descriptive messages rather than raw XML.

1. Open Event Viewer​

• Press Win + R, type: eventvwr.msc, and press Enter.
• Or Start → Windows Tools → Event Viewer.

2. Navigate to the System log​

• In the left pane expand Windows Logs and click System. The middle pane lists all System events, newest first.

3. Filter to shutdown/restart events​

• In the right Actions pane click Filter Current Log…
• In <All Event IDs> type: 41,1074,6005,6006,6008 and click OK.
• Optionally set a date range if you’re investigating a specific timeframe.

This immediately trims thousands of entries to the shutdown‑related events you care about. Event Viewer rows include Date/Time, Source, and Event ID, and double‑clicking opens a message that often names the initiating process and user (for 1074).

4. Interpret common patterns​

• 1074 + 6006 in sequence — clean, intentional shutdown.
• 6005 on boot — event log started; use as boot indicator.
• 6008 or 41 — unexpected shutdown; investigate hardware, PSU, drivers, or power events.

Event Viewer gives readable context (who, when, process name). It’s the first tool for human‑driven diagnosis.

---

Method 2 — PowerShell: scriptable, flexible, and remote-ready​

PowerShell is the preferred choice for automation, remote diagnostics, and creating reports. Use Get‑WinEvent (modern) rather than Get‑EventLog (legacy) to avoid missing descriptions.

Quick command: show recent shutdown events​

Get-WinEvent -FilterHashtable @{LogName='System'; ID=41,1074,6005,6006,6008} -MaxEvents 50 |
  Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap -AutoSize

This prints the 50 most recent shutdown/restart related events, with full messages for easy triage. If you prefer a slimmed view:

Get-WinEvent -FilterHashtable @{LogName='System'; ID=41,1074,6008} -MaxEvents 20 |
  ForEach-Object {
    [PSCustomObject]@{
      Time = $_.TimeCreated
      EventID = $_.Id
      Type = switch($_.Id) {
        41 {'Unexpected Shutdown/Power Loss'}
        1074 {'User/System Initiated'}
        6008 {'Previous Shutdown Was Unexpected'}
        6006 {'Clean Shutdown'}
        6005 {'System Started'}
      }
      Details = $_.Message.Split("`n")[0]
    }
  } | Format-Table -AutoSize

Export to CSV for analysis​

Get-WinEvent -FilterHashtable @{LogName='System'; ID=1074,6008,41} |
  Select-Object TimeCreated, Id, LevelDisplayName, Message |
  Export-Csv "C:\ShutdownHistory.csv" -NoTypeInformation

This creates a spreadsheet you can share or analyze in Excel.

Why use Get‑WinEvent?​

Get‑WinEvent handles modern event channels and avoids “description not found” problems that sometimes plague Get‑EventLog. Use it for robust, scriptable results — ideal for remote diagnostics across many machines.

---

Using wevtutil (Command Prompt): universal fallback​

If PowerShell isn’t available, the built‑in wevtutil works on any Windows 11 system:
wevtutil qe System /q:"*[System[(EventID=1074 or EventID=6008 or EventID=41)]" /f:text /c:20
This returns the last 20 matching System events in text format. The syntax is more cumbersome but useful for constrained environments such as recovery consoles or legacy scripts.

---

Method 3 — third‑party utilities: quick and user‑friendly​

For fast, friendly tables and exports, small portable utilities can be helpful.

• TurnedOnTimesView (NirSoft) — scans Event Log and presents startup and shutdown times in a simple table. Portable, no install required.
• LastActivityView (NirSoft) — aggregates various system activities including shutdowns, logons, and recent application usage.

These tools are widely used by technicians for quick inspections and CSV exports. However, treat third‑party tools with care: endpoint protection may flag portable utilities and corporate policy may restrict their use. Always download from the vendor’s official site and verify checksums if available.
Caution: claiming a third‑party tool is “better” than built‑in tools is subjective — some admins prefer Event Viewer for its provenance and auditability, while others value the immediacy of a NirSoft table. Validate in your environment before relying on them.

---

Troubleshooting common shutdown anomalies​

Finding a suspicious Event ID is just the start. Here are common causes and how to investigate them.

Frequent Event ID 41 or 6008​

This signals repeated unclean shutdowns. Common culprits:

• Faulty power supply or unstable mains power.
• Overheating or thermal shutdowns.
• Driver crashes or firmware/BIOS issues.
• Forced power cuts or user‑initiated physical resets.

Investigative steps:

• Check Reliability Monitor and Application/System logs around the same timestamp to spot driver or app crashes.
• If multiple machines show the pattern simultaneously, rule out site power issues.
• Run hardware diagnostics (disk SMART, memory test, PSU check) and update BIOS/firmware if needed. fileciteturn0file2turn0file7

No shutdown events appearing​

• Ensure logs aren’t being auto‑cleared or restricted by a log rotation policy.
• Check the System log properties and increase maximum log size if older entries are rolling off.
• Confirm you're looking at the System log (not Application or Security).

Times appear incorrect​

• Event Viewer displays times in local timezone, but some export tools or remote logs use UTC. Verify timezone settings on the machine and in any collector you use.

---

Fast Startup and hybrid shutdown caveat​

Windows 11’s Fast Startup (hybrid shutdown) changes what “shutdown” means: a user‑initiated shutdown may actually perform a partial hibernation instead of a full kernel teardown. This can affect whether certain Event IDs appear exactly as expected.
If you need precise shutdown auditing (for forensic or reproducible testing), consider disabling Fast Startup via Power Options while you collect evidence — but be aware of the tradeoffs (slower boots vs. cleaner shutdown logs).

---

Automating monitoring and alerts​

For administrators who want ongoing visibility, schedule a short PowerShell monitor to run daily and alert on unexpected shutdowns.
Options:

• Email alerts (requires SMTP). Script checks last 24 hours for Event IDs 41 or 6008 and emails IT if any appear.
• Local notifications (system balloon or Windows 11 toast) for workstations that shouldn’t require server access.
• Central collectors/SIEM: forward Event Logs to a central server and create rules/alerts for 41/6008 events.

Example outline for a scheduled script:

• Save a PowerShell script that queries Get‑WinEvent for ID=41,6008 in the last 24 hours.
• If events found, write a daily summary to a secured log folder and optionally send an email or toast.
• Schedule via Task Scheduler (taskschd.msc) with highest privileges and a daily trigger. fileciteturn0file1turn0file16

Security note: scripts that send email will require storing or supplying credentials; protect these credentials and follow organizational policies.

---

Forensics and completeness: limits and blind spots​

Windows event logs are powerful but not omniscient. Important caveats:

• Windows will not, by default, capture every single user‑level app closure. For full process start/stop auditing you must enable continuous monitoring (Procmon or persistent PowerShell/WMI logging).
• Third‑party tools can augment visibility but introduce AV/endpoint concerns and policy issues.
• Achieving perfect completeness requires always‑on logging, which has storage, privacy, and performance tradeoffs. Plan retention, rotation, and access controls accordingly.

If your scenario requires legal‑grade forensics, centralize logs and use enterprise SIEM/EDR solutions with proper chain‑of‑custody controls.

---

Practical workflows and recommended approach​

• Quick check (one-off): Open Event Viewer, filter for 41,1074,6005,6006,6008. Read the top messages.
• Quick table: Run TurnedOnTimesView or LastActivityView for a fast CSV table, but verify authenticity of the executable first.
• Automation & reporting: Create a PowerShell Get‑WinEvent script, export to CSV, schedule by Task Scheduler, and forward to a central collector if needed. fileciteturn0file1turn0file16
• Deep forensics: Correlate Kernel‑Power/6008 with Application and System logs, Reliability Monitor, and, if necessary, Procmon traces for a reproducing window.

---

Security, policy, and safety considerations​

• Validate any third‑party binaries before running them; portable utilities often trigger heuristics in antivirus engines. This is usually a benign false positive, but always confirm the vendor distribution and checksums.
• In corporate environments, coordinate with IT and comply with auditing/privacy rules before enabling continuous logging or installing tools that monitor user activity. Logging can capture personally identifiable behavior.
• Protect exported logs (CSV, text) with proper ACLs and rotate archives to reduce risk of data leakage.

---

Quick reference: commands and Event IDs​

• Event Viewer filter: 41,1074,6005,6006,6008.
• PowerShell basic:
• Get recent events: Get-WinEvent -FilterHashtable @{LogName='System'; ID=41,1074,6005,6006,6008} -MaxEvents 50
• Export CSV: ... | Export-Csv "C:\ShutdownHistory.csv" -NoTypeInformation
• wevtutil:
• wevtutil qe System /q:"*[System[(EventID=1074 or EventID=6008 or EventID=41)]" /f:text /c:20

Remember: use Get‑WinEvent (modern) for the best results. Get‑EventLog is legacy and can miss descriptions for newer channels.

---

Final analysis — strengths and risks​

Windows 11 provides robust, timestamped shutdown history via the System event log; when combined with PowerShell and small utilities, administrators and power users can quickly build reliable monitoring or ad hoc investigations. The main strengths are:

• Rich contextual messages (Event Viewer + 1074 gives who/what/reason).
• Scriptability (Get‑WinEvent provides automation and exports).
• Portability (wevtutil and portable NirSoft tools work without installs).

The principal risks and limitations are:

• Incomplete capture unless continuous logging is enabled — normal app closures aren’t always recorded by default.
• Endpoint policy and AV flags when using third‑party utilities.
• Misleading timestamps if timezone differences or hybrid shutdown are in play.

For most users: start with Event Viewer for context, use PowerShell for repeatable checks or automation, and reserve third‑party utilities for quick summaries — always validating binaries and respecting policy. fileciteturn0file1turn0file16

---

Checking shutdown history in Windows 11 is a small investigative skill that pays big dividends: the right Event IDs and a few PowerShell lines quickly reveal whether a restart was planned or symptomatic of a deeper problem. Use the steps above to locate, interpret, and — when required — automate alerts for unexpected shutdowns, while keeping security and policy considerations in mind. fileciteturn0file1turn0file2

---

Source: H2S Media How to Check Shutdown History in Windows 11 using GUI or Command line