Get EventViewer Errors

What the Windows Event Viewer retriever does

This Automox Worklet™ pulls the most recent error entries from Windows Event Viewer and writes them to the Automox Activity Log for remote review. The Worklet queries the System and Application channels using Get-EventLog with -EntryType Error, returning the newest N entries per channel as set by the $events variable in the remediation script.

Each returned event is projected through Select-Object with the properties TimeGenerated, EventID, EntryType, Message, and Source, so the operator sees the same fields Event Viewer surfaces in the legacy GUI. Get-EventLog reads the classic Windows event log API, which covers the Application and System channels on Windows 7, Windows 10, Windows 11, and Windows Server 2008 R2 through 2022.

Output is grouped by channel with a header line for each section and a `---` separator between events. The remediation streams everything to stdout, which Automox captures into the Activity Log entry for that policy execution.

Why pull event log errors from every endpoint

When a user reports a crash, a driver fault, or a service that will not start, the answer almost always sits in Event Viewer. The problem is reaching it. Opening eventvwr.msc on every affected endpoint over RDP does not scale past a handful of hosts, and remote PowerShell to a fleet of laptops fails the moment one is asleep, off-network, or on a different VPN segment.

The signal you want is concrete: Event ID 7034 (service crashed), 41 (kernel-power unexpected shutdown), 1000 (application crash with faulting module), 6008 (previous unexpected shutdown), or a Source like Microsoft-Windows-WHEA-Logger flagging hardware faults. The Worklet pulls those exact entries from every targeted endpoint on its next Automox check-in, no remote session required.

Running this Worklet against your Windows workstation group, or invoking it as a FixNow during an incident, turns the Application and System logs into a centrally readable data source through the Automox console. The Event IDs that matter come back attached to the originating endpoint and the policy run that pulled them, so cross-host patterns surface in one view rather than across ten RDP sessions.

How Event Viewer error retrieval works

1. Evaluation phase: The evaluation script runs Exit 1 unconditionally, so Automox always proceeds to remediation. This is a diagnostic Worklet, not a compliance check; the evaluation script's role is to signal that a fresh collection should run on every policy execution rather than gate the remediation behind a passing state.

2. Remediation phase: The remediation script writes a header ("10 Most Recent SYSTEM Log Errors"), then calls Get-EventLog -LogName System -EntryType Error -Newest $events and pipes each event through Select-Object -Property TimeGenerated, EventID, EntryType, Message, Source. It repeats the same block for the Application channel. Each event is preceded by a `---` separator line. Output streams directly to stdout, which Automox captures into the Activity Log entry for that policy execution.

Event Viewer retrieval requirements

• Windows 7 / Server 2008 R2 or later (Get-EventLog ships with PowerShell 2.0 on these releases and is supported on Windows 10, 11, and Windows Server 2012 through 2022)

• PowerShell 2.0 or higher

• The Automox agent runs as SYSTEM, which already has read access to the Application and System channels through Get-EventLog

• Set the $events variable at the top of the remediation script to the number of newest errors to retrieve per channel (default '10', recommended range 5–50; values above 100 will inflate the Activity Log entry size)

• Applies to both workstations and servers (device_type WORKSTATION and SERVER); the Worklet does not modify endpoint state, so it is safe to run on production hosts during business hours

Expected Event Viewer output after collection

After the policy runs, open the endpoint's Automox Activity Log entry for that execution. The remediation stdout will contain two labeled sections ("10 Most Recent SYSTEM Log Errors" and "10 Most Recent APPLICATION Log Errors"), each followed by up to $events entries projected as TimeGenerated, EventID, EntryType, Message, and Source, with a `---` line between events.

Validate the output locally on one endpoint first by running Get-EventLog -LogName System -EntryType Error -Newest 10 | Select-Object TimeGenerated, EventID, EntryType, Message, Source in an elevated PowerShell session and comparing the result to the Activity Log entry from the same window. Search the Automox console's Activity Log across the fleet for a recurring event ID (for example, EventID 41 for unexpected reboots or EventID 7034 for repeated service crashes) to identify the endpoints sharing a root cause. For audit evidence, export the policy run's Activity Log entry and store it with the incident ticket; the timestamps in TimeGenerated are in the endpoint's local timezone as emitted by Get-EventLog.