Why does my Windows Event Log keep showing errors?

What this covers

A Windows event log full of red entries is a symptom, not a diagnosis. The log tells you which component is unhappy and how often, and that is enough to decide what to do next — but only if you query it instead of scrolling it. This walkthrough pulls the relevant errors, checks the other logs where faults hide, and then confirms whether the problem is actually gone.

Symptom

List the real errors before you fix anything

Event Viewer buries you in noise; a filtered query returns only the entries that matter. Level and start-time filtering happens inside the log service, so it answers in about a second even on a busy machine, and you can widen or narrow the window without re-reading the whole log. Look for a ProviderName plus Event Id pair that keeps repeating — that pair is your actual problem, not the individual messages. If the table comes back empty there are simply no Error-level entries in the System log for that period: widen the date range or point LogName at Application instead.

$ Get-WinEvent -FilterHashtable @{LogName='System'; Level=2; StartTime=(Get-Date).AddDays(-7)} -MaxEvents 20 | Format-Table TimeCreated, Id, ProviderName, Message -AutoSize

Read the same log without PowerShell

Use this when PowerShell is locked down by policy, when you are already sitting in cmd, or when you want plain text you can paste straight into a ticket. It queries the System log for error-level events, newest first, and prints them as readable text with no formatting layer in between. A useful cross-check: if this finds errors that the PowerShell query did not, your earlier filter — wrong log name or too narrow a time window — was hiding them.

$ wevtutil qe System /q:"*[System[(Level=2)]]" /c:20 /rd:true /f:text

Check the Security log if logons are involved

Skip this unless the errors mention authentication, access, or you suspect sign-ins at odd hours. The Security log records every successful sign-in with the account name and logon type, which is what turns a vague 'access errors' complaint into a specific account or session to investigate. Read it as a timeline rather than line by line: unknown account names, or logon types that should not appear outside working hours, usually point at a service account or a remote session. An empty result means nobody signed in interactively during the period you queried.

$ Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 10 | Select-Object TimeCreated, @{n='Account';e={$_.Properties[5].Value}}, @{n='Type';e={$_.Properties[8].Value}}

Grep exported or application logs for repeats

Not every error reaches the event log — plenty of applications keep their own text log next to the program. Searching those by pattern returns the file, the line number and the matching line, which is exactly what you need to count how often something fails and to line it up against the timestamps from your event query. A match list that simply stops at a certain time is a strong hint the problem ended there, and the last matching line tells you when.

$ Select-String -Path "$env:USERPROFILE\Documents\*.log" -Pattern "error"

Clear the noisy logs — but only after you saved them

This wipes every event log on the machine, so it is only appropriate once you have exported whatever you need. A clean slate makes anything new stand out immediately and it is a legitimate privacy step on a machine you are about to hand over. Be clear about what it does and does not do: it removes the backlog of noise, it does not repair the underlying fault, so the same provider should still be watched afterwards. Note the exact time right after clearing — any entry that shows up in the following minutes is happening now, not history.

$ wevtutil el | ForEach-Object { wevtutil cl "$_" }

Watch the log grow live

Tail the application's own log file while you reproduce the problem, or right after you apply a change. Seeing lines arrive with fresh timestamps proves the program is running and shows whether the error comes back on the next attempt. The tell-tale failure mode: if nothing at all is written while you reproduce the fault, then that log is not where the problem lives and you should go back to the event query rather than keep watching a silent file.

$ Get-Content 'C:\Logs\app.log' -Tail 20 -Wait

Keep a record of the whole session

A transcript writes every command and its output to a file on your desktop, which is what lets you compare the before query with the after query instead of relying on memory. If you can, start it at the very beginning of the investigation; starting it now still documents the closing check and any remaining errors. The resulting file is plain text, so it can be searched, attached to a ticket, or handed to a colleague without any conversion.

$ Start-Transcript -Path "$env:USERPROFILE\Desktop\session.log"

How to confirm it worked

Set the query's start time to now and run it again: the offending provider and event ID should no longer produce new entries. If the same errors keep arriving at the same rate, the root cause is still present and clearing the log only hid it temporarily.

Sources

• 4624(S): An account was successfully logged on
  Microsoft Learn · vendor-doc · 2026-09-17
  Evidence: Defines Windows security event 4624 for successful logons and documents its fields, including Account Name (index 5) and Logon Type (index 8).
• Select-String (Microsoft.PowerShell.Utility)
  Microsoft Learn · vendor-doc · 2026-09-17
  Evidence: Documents Select-String with -Path, -Pattern (regex), -CaseSensitive and -SimpleMatch parameters for searching file content.
• Wevtutil - Windows Event Log Utility
  SS64 · community · 2026-09-17
  Evidence: Documents the el (enumerate logs) and cl (clear log) subcommands.
• Get-Content - PowerShell
  SS64 · technical · 2026-09-17
  Evidence: SS64 lists -Tail and -Wait parameters, noting -Wait polls the file and outputs new lines when added.
• Get-Content | Microsoft Learn
  Microsoft · vendor-doc · 2026-09-17
  Evidence: Microsoft documents Get-Content -Tail <n> to return the last n lines and -Wait to keep the file open and emit new lines as they are appended.
• Get-WinEvent
  Microsoft Learn · vendor-doc · 2026-09-17
  Evidence: Documents FilterHashtable parameters including LogName, Level, and StartTime for server-side filtering.
• Get-WinEvent - SS64
  SS64 · technical · 2026-09-17
  Evidence: Shows FilterHashtable usage examples for querying System and Application logs by level and date range.
• wevtutil - Windows Commands
  Microsoft Learn · vendor-doc · 2026-09-17
  Evidence: Documents wevtutil, including the query-events (qe) command with /q XPath filter, /c count, /rd reverse direction and /f text format.

Last verified: 2026-09-22

Related guides