Windows Event Log CMD: Event Viewer, wevtutil, PowerShell

To open Windows Event Viewer immediately, press Win+R, enter eventvwr.msc, and press Enter. The same command works from Command Prompt or PowerShell. Use Event Viewer for interactive browsing, wevtutil for built-in CMD queries and exports, and PowerShell's Get-WinEvent for structured filtering and automation.

The commands below follow Microsoft's current Windows Event Log documentation for Windows 10, Windows 11, and supported Windows Server releases. Test queries and administrative policy changes in a non-production system first. The examples are source-validated; they were not executed on Windows in this environment.

Open Event Viewer from Run, CMD, or PowerShell

Run this from the Run dialog, Command Prompt, or PowerShell:

eventvwr.msc

Event Viewer is useful when you need to browse the log tree, inspect an event's Details tab, or build a custom view. It is not the best interface for repeatable collection. Save the corresponding command-line query with an incident record when reproducibility matters.

The familiar top-level Windows logs are:

• Application for application and service events;
• System for operating-system and driver events;
• Security for audited security events, subject to audit policy and access rights;
• Setup for installation and servicing events;
• ForwardedEvents for events collected through Windows Event Forwarding.

Applications and Windows components also expose operational channels such as Microsoft-Windows-PowerShell/Operational. Never assume that a channel exists or is enabled on every host: enumerate it first.

List Windows event logs and inspect a channel

wevtutil ships with Windows. List every registered log from CMD:

wevtutil el

Inspect a particular log's configuration and status:

wevtutil gl System
wevtutil gli System

gl shows configuration such as whether the channel is enabled, its backing file, and its maximum size. gli shows status information. These forms read configuration; do not confuse gl with sl, which changes it.

PowerShell can return structured log objects:

Get-WinEvent -ListLog * |
    Select-Object LogName, RecordCount, IsEnabled, LogMode, MaximumSizeInBytes

The list can be long. Filter it by name when you know the component:

Get-WinEvent -ListLog 'Microsoft-Windows-PowerShell/*' |
    Select-Object LogName, RecordCount, IsEnabled

Some channels and fields require an elevated, authorized session. Elevation does not override organizational policy; use an account explicitly permitted to read the target log.

Show the newest events with wevtutil

Return the 20 newest System events in human-readable text:

wevtutil qe System /c:20 /rd:true /f:text

The important switches are:

• qe queries events;
• /c:20 limits the result count;
• /rd:true reads in reverse direction, so newest events appear first;
• /f:text renders messages for people.

Microsoft documents text as the default output format. The examples keep /f:text explicit and use /rd:true explicitly when newest-first output is required.

Use XML when exact event fields matter:

wevtutil qe System /c:5 /rd:true /f:xml

Rendered messages can be localized, truncated by downstream formatting, or unavailable when provider message resources are missing. XML retains the event's structured System and EventData values, making it safer for automation than searching rendered prose.

Filter wevtutil results with XPath

Windows Event Log supports a restricted subset of XPath 1.0. Its documented timediff() function calculates a difference in milliseconds and uses the current system time when its second argument is omitted. This query returns Critical and Error events from approximately the last hour:

wevtutil qe System /q:"*[System[(Level=1 or Level=2) and TimeCreated[3600000 >= timediff(@SystemTime)]]]" /rd:true /c:50 /f:text

The window is evaluated by the computer executing the event query, so check its clock. For an exact start time, prefer Get-WinEvent -FilterHashtable with a StartTime value rather than comparing ISO 8601 timestamp strings inside the restricted XPath subset. To filter by event ID:

wevtutil qe System /q:"*[System[EventID=41]]" /rd:true /c:20 /f:text

To match more than one ID:

wevtutil qe System /q:"*[System[(EventID=41 or EventID=6008)]]" /rd:true /c:20 /f:text

These commands only select matching records; an ID's meaning depends on its provider and channel. Record the channel, ProviderName, event ID, timestamp, computer, and event data together. An event ID alone is not globally unique.

Keep XPath predicates focused. Microsoft's Event Log engine supports only part of XPath 1.0, and complex multi-channel selection is better represented as a structured XML query. For ordinary investigation, start broad, confirm records exist, and add one condition at a time.

Query events with PowerShell Get-WinEvent

Get the newest 20 System events:

Get-WinEvent -LogName System -MaxEvents 20 |
    Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

For large logs, filter inside Get-WinEvent instead of retrieving everything and piping it to Where-Object. FilterHashtable, FilterXPath, and FilterXml let the Windows Event Log service apply the query before PowerShell receives the results.

This returns Critical and Error events created in the last hour:

$start = (Get-Date).AddHours(-1)

Get-WinEvent -FilterHashtable @{
    LogName  = 'System'
    Level    = 1, 2
    StartTime = $start
} -MaxEvents 100 |
    Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

Windows event levels use numeric values in filters:

Level 0 means LogAlways and can appear in provider-defined events. Do not assume every provider uses every level consistently.

Filter by channel, provider, event ID, and time together when you know the event source:

$start = (Get-Date).AddHours(-4)

Get-WinEvent -FilterHashtable @{
    LogName     = 'System'
    ProviderName = 'Microsoft-Windows-Kernel-Power'
    Id          = 41
    StartTime   = $start
} -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

Other supported hashtable keys include EndTime, UserID, Path, and Data. PowerShell 6 and later also allow a named event-data field to be used as a key; that form is not available in Windows PowerShell 5.1. LogName and ProviderName accept wildcards; Id and Level accept numeric arrays. The provider shown as Source in Event Viewer may not be the exact provider name required by the API. Check the event's XML or Details tab, or enumerate providers:

Get-WinEvent -ListProvider * |
    Select-Object Name, LogLinks

For a known provider, inspect the logs and event metadata it publishes:

Get-WinEvent -ListProvider 'Microsoft-Windows-Kernel-Power'

Use XPath from PowerShell

The same Windows Event Log XPath subset works with Get-WinEvent. This version uses the documented relative-time function rather than embedding a timestamp string:

$windowMilliseconds = 60 * 60 * 1000
$query = "*[System[(Level=1 or Level=2) and TimeCreated[$windowMilliseconds >= timediff(@SystemTime)]]]"

Get-WinEvent -LogName System -FilterXPath $query -MaxEvents 50 |
    Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

Use FilterHashtable for common field filters because it is easier to read and safely construct. Use XPath for predicates that a hashtable cannot express. Avoid building XPath by concatenating untrusted text; malformed or hostile input can change a query's meaning.

Read and preserve saved EVTX files

An .evtx export preserves native event records more faithfully than copied console text, CSV, or JSON. Before an investigation changes the machine, export the complete relevant log to a protected case directory:

wevtutil epl System "C:\Cases\System-20260915.evtx"

This command writes a new file; it does not clear the source log. By default, the destination must not already exist. Do not add /ow:true unless overwriting an existing evidence file is deliberate and authorized.

Hash the exported file and record the hash separately:

Get-FileHash -Path 'C:\Cases\System-20260915.evtx' -Algorithm SHA256

Read the saved file without importing it into the local logs:

Get-WinEvent -Path 'C:\Cases\System-20260915.evtx' -MaxEvents 20 |
    Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

Apply a structured filter to a saved file with the Path key:

Get-WinEvent -FilterHashtable @{
    Path  = 'C:\Cases\System-20260915.evtx'
    Level = 1, 2
} |
    Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, Message

Message rendering can fail on another computer if the event provider or its locale-specific resources are absent. That does not necessarily mean the EVTX record is corrupt. Preserve the original file and inspect structured XML when messages are unavailable:

Get-WinEvent -Path 'C:\Cases\System-20260915.evtx' -MaxEvents 1 |
    ForEach-Object { $_.ToXml() }

Treat exported logs as sensitive evidence. Restrict access, preserve timestamps and hashes, document custody, and avoid opening the only copy in tools that may modify metadata.

Query a remote Windows computer safely

Get-WinEvent can query one remote computer at a time. Prompt for credentials rather than putting a password in command history:

$credential = Get-Credential
$start = (Get-Date).AddMinutes(-30)

Get-WinEvent -ComputerName 'server01.example.net' -Credential $credential `
    -FilterHashtable @{
        LogName  = 'System'
        Level    = 1, 2
        StartTime = $start
    } -MaxEvents 100

This feature does not require PowerShell remoting, but the remote Event Log service and applicable firewall rules must permit access. Use a resolvable host name, an explicitly authorized account, and the organization's approved network path. Do not open broad firewall access merely to make a query work.

wevtutil also supports remote queries, but its password option can expose secrets in process listings or shell history. If a separate identity is necessary, use its interactive password prompt rather than including the password on the command line. For repeated collection across many hosts, use a managed Windows-capable collector or Windows Event Forwarding instead of ad hoc remote polling.

Audit process command lines with Event ID 4688

Process command-line auditing can help answer which executable ran and with which arguments, but it is a configuration change that requires administrative authorization and a privacy review. Microsoft requires both policies:

1. Enable Audit Process Creation under Advanced Audit Policy Configuration > Detailed Tracking.
2. Enable Include command line in process creation events under Administrative Templates > System > Audit Process Creation.

The second setting has no effect unless process-creation auditing is enabled. When both are active, new process events use Security event ID 4688 and can include the command line.

Command-line arguments are stored in plain text in the Security log. Passwords, tokens, personal data, and sensitive file paths passed as arguments can therefore become visible to anyone permitted to read that log. Fix applications and scripts that put secrets in arguments before enabling this policy broadly. Apply the policy through the organization's normal Group Policy or device-management process, not an untracked local change.

After an authorized change, verify recent 4688 records:

$start = (Get-Date).AddMinutes(-10)

Get-WinEvent -FilterHashtable @{
    LogName  = 'Security'
    Id       = 4688
    StartTime = $start
} -MaxEvents 20 |
    Select-Object TimeCreated, Id, ProviderName, Message

Confirm that expected test processes generate events and that the command-line field is populated. Also verify the effective audit policy; basic audit policy can conflict with or overwrite advanced audit settings. Do not treat the existence of a 4688 event as proof that every process was captured under every failure or policy state.

Export readable output without losing the original

PowerShell's default table view may truncate long messages. Use a list for interactive inspection:

Get-WinEvent -LogName System -MaxEvents 5 |
    Format-List TimeCreated, Id, LevelDisplayName, ProviderName, RecordId, Message

For analysis in another tool, export selected fields as UTF-8 CSV:

Get-WinEvent -LogName System -MaxEvents 100 |
    Select-Object TimeCreated, Id, LevelDisplayName, ProviderName, RecordId, Message |
    Export-Csv -Path 'C:\Cases\system-events.csv' -NoTypeInformation -Encoding utf8

CSV is a derived convenience copy, not a replacement for the EVTX evidence. Newlines inside messages, localization, and type conversion can affect downstream parsing. Keep the EVTX export and its hash alongside any transformed data.

Prefer structured filters over searching message text with findstr, Select-String, or grep. Message wording changes across providers, Windows versions, and locales. Provider name, event ID, level, timestamp, record ID, and structured event data are more stable investigation keys.

Troubleshoot common Windows Event Log command failures

Access is denied

Security and some operational logs have restricted access. Confirm that the account is authorized, then open an elevated shell only when policy permits it. For remote reads, verify both remote log permissions and firewall access. Do not weaken a channel's access control as a shortcut.

No events were found

Start with an unfiltered query and a small result limit. Confirm the exact log name with wevtutil el or Get-WinEvent -ListLog *, then add the provider, event ID, level, and time window one by one. Check the host clock and remember that StartTime is evaluated as a date-time value on the system running the query.

Some operational channels are disabled until a component or policy enables them. Reading a disabled or empty channel cannot reconstruct events that were never recorded.

The provider name is rejected

Use the exact provider from the event XML or Get-WinEvent -ListProvider *. Event Viewer's display label or Source column is not always the API identifier. Provider availability also varies by installed roles, applications, and Windows version.

The message cannot be rendered

The record may exist while its provider metadata or language resource is missing. Inspect ToXml(), retain the original EVTX, and analyze it on a compatible system with the corresponding provider installed. Do not discard a record because its friendly message is unavailable.

Output is truncated or looks corrupted

PowerShell display formatting is not the underlying object. Select explicit fields, use Format-List for the console, and choose UTF-8 explicitly when exporting text. With wevtutil, use /f:xml for structured output or /uni:true when Unicode console output is needed.

Older events have disappeared

Windows logs have maximum sizes and retention modes. Depending on channel configuration, new events can overwrite the oldest records or be discarded when the log is full. wevtutil gl LOG_NAME reveals the current settings. Changing size or retention is an administrative action: assess disk capacity, compliance requirements, and collection health before modifying it.

When command-line queries are no longer enough

eventvwr.msc, wevtutil, and Get-WinEvent are excellent for one host or a bounded investigation. They do not by themselves provide durable, centralized search across a fleet. Centralization becomes useful when teams need to correlate hosts, retain records beyond local rotation, alert on defined conditions, or investigate without repeatedly opening access to production servers.

Use a Windows-capable collector to read approved channels, preserve source fields, buffer during network interruption, and forward over a documented protocol. The collector's parser and mapping determine which Windows fields become top-level destination fields, so validate that boundary with a known test event. Keep local or exported EVTX evidence for cases where normalized records are insufficient.

Fluxtail log management is a paid, self-service option with Starter and Pro plans for teams that want a logs-focused destination. A separately configured collector can forward Windows events through a receiver protocol Fluxtail documents for the account. Fluxtail then provides named streams, Live Tail, and search and filters for the fields the collector actually sends. It is not a Windows Event Log collector and does not replace EVTX evidence handling.

Fluxtail's built-in AI chat and its hosted MCP endpoint are separate interfaces. AI can assist an investigation, while the account-bound hosted MCP connection uses OAuth with PKCE so an authorized external agent can query within the connected account's permissions. Hosted MCP operator tools can change streams and receivers, but each mutation is proposed first and requires a short-lived confirmation token before it is applied. Keep raw events as the source of truth and review agent-generated conclusions against the underlying records.

If centralized Windows log search fits the operational model, create a Fluxtail account, configure a supported receiver, and test the full path with a non-sensitive marker event before expanding collection.

Windows Event Log command checklist

• Open the GUI with eventvwr.msc.
• Enumerate exact channel and provider names before scripting filters.
• Use wevtutil qe for portable CMD queries and Get-WinEvent for structured PowerShell work.
• Filter at query time by channel, provider, ID, level, and time instead of grepping rendered messages.
• Export the full relevant EVTX before making changes; hash and protect it.
• Never put credentials or receiver tokens in command-line arguments or saved shell history.
• Treat remote access, audit policy, channel configuration, and retention changes as authorized administrative work.
• Verify 4688 command-line auditing only after both required policies and the privacy risks are addressed.
• Preserve original records when producing CSV, JSON, screenshots, or normalized central copies.
• Validate collector mappings and delivery with a harmless marker before relying on centralized search.

Microsoft's wevtutil reference, Get-WinEvent reference, FilterHashtable guidance, Windows Event Log XPath rules, and process command-line auditing guidance are the authoritative starting points for version-specific details.