⚠ CrashDecoder

Finding Your Crash History in Windows

One crash tells you almost nothing. A timeline of thirty crashes tells you whether a machine is stable, degrading, or already past saving - and it is the difference between a support call that ends in a replacement and one that ends in a suggestion to reinstall Windows. Everything needed to build that timeline is already on the machine.

Updated 2026-07-28

Start with Reliability Monitor

The fastest overview in Windows, and the least known. Press Win+R and run:

perfmon /rel

You get a calendar with a line graph, one column per day, marking every crash, failed update, driver installation and application fault. Click any red marker for details.

What makes it valuable is not the individual entries - it is the shape. A machine that was stable for two years and started producing failures three weeks ago tells a very different story from one that has failed intermittently since the day it was bought. Reliability Monitor shows you that shape in about ten seconds.

What to look for

Note the date of the first failure, not just the recent ones. Then ask what changed around then - a Windows feature update, a driver, new hardware, a house move, a hot spell. That correlation is often the whole answer.

Event Viewer for the detail

Reliability Monitor is a summary built from the event logs. When you need specifics, go to the source. Run eventvwr, expand Windows Logs, and select System.

The entries that matter for crash work:

SourceEvent IDWhat it means
BugCheck1001The machine rebooted from a stop error. The message contains the full bugcheck code and all four parameters.
Kernel-Power41The system rebooted without shutting down cleanly. Present after every crash, but also after a power loss or a hard lock with no dump.
WHEA-Logger17, 18, 19, 47Hardware errors reported by the platform itself. See Event 17.
Display4101The display driver timed out and recovered - the non-fatal form of VIDEO_TDR_FAILURE.
disk / Ntfs7, 51, 55, 98Storage errors. Bad blocks, controller problems, filesystem corruption.
EventLog6008The previous shutdown was unexpected.

A Kernel-Power 41 with no accompanying BugCheck 1001 is worth noticing specifically: it means the machine died without managing to write a dump, which is a harder failure than an ordinary blue screen and leans toward power or hardware.

Building the timeline with PowerShell

Clicking through Event Viewer does not scale past a handful of entries. These pull the same data into something you can actually read.

Every stop error, with its parameters:

Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} |
  Where-Object { $_.Message -match 'bugcheck was' } |
  Select-Object TimeCreated, Message |
  Format-List

Count of every hardware error by event ID:

Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger'} |
  Group-Object Id | Sort-Object Count -Descending |
  Format-Table Name, Count -AutoSize
Filter by provider, not by ID alone

Event IDs are only unique within a provider. If you filter the System log on Id=17,18,19,47 without naming a provider you will also collect unrelated events - ID 19 in the System log is also Windows Update reporting a successful installation, and it fires constantly. A crash timeline padded with update entries is worse than no timeline, because it buries the signal you are trying to show someone.

The queries below pair each provider with its own IDs for that reason.

A combined timeline of everything relevant:

$since = (Get-Date).AddDays(-90)
$filters = @(
  @{ LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger' }
  @{ LogName='System'; ProviderName='Microsoft-Windows-Kernel-Power'; Id=41 }
  @{ LogName='System'; ProviderName='Microsoft-Windows-WER-SystemErrorReporting'; Id=1001 }
  @{ LogName='System'; ProviderName='EventLog'; Id=6008 }
  @{ LogName='System'; ProviderName='Display'; Id=4101 }
)
$events = foreach ($f in $filters) {
  $f['StartTime'] = $since
  try { Get-WinEvent -FilterHashtable $f -ErrorAction Stop } catch { }
}
$events | Sort-Object TimeCreated |
  Select-Object TimeCreated,
                @{n='Source';e={$_.ProviderName -replace '^Microsoft-Windows-',''}},
                Id,
                @{n='Summary';e={($_.Message -split "`n")[0]}} |
  Format-Table -AutoSize -Wrap

That last one is the useful artefact. It shows you what preceded each crash, which is where the actual diagnosis usually lives - a burst of WHEA entries in the ninety seconds before a stop error is a completely different finding from a stop error arriving out of nowhere.

Exporting it properly

If there is any chance this becomes a warranty conversation, export before you troubleshoot. Reinstalling Windows destroys the evidence, and the evidence is what makes the case.

To CSV, for reading and sharing:

$filters = @(
  @{ LogName='System'; ProviderName='Microsoft-Windows-WHEA-Logger' }
  @{ LogName='System'; ProviderName='Microsoft-Windows-Kernel-Power'; Id=41 }
  @{ LogName='System'; ProviderName='Microsoft-Windows-WER-SystemErrorReporting'; Id=1001 }
  @{ LogName='System'; ProviderName='EventLog'; Id=6008 }
  @{ LogName='System'; ProviderName='Display'; Id=4101 }
)
$events = foreach ($f in $filters) {
  try { Get-WinEvent -FilterHashtable $f -ErrorAction Stop } catch { }
}
$events | Sort-Object TimeCreated |
  Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message |
  Export-Csv "$env:USERPROFILE\Desktop\crash-history.csv" -NoTypeInformation -Encoding UTF8

The raw log, which a technician can open directly:

wevtutil epl System "$env:USERPROFILE\Desktop\system-log.evtx"

Copy your minidump folder alongside it. Between the timeline, the exported log and the dumps, you have a case rather than an anecdote.

Reading the pattern

What the timeline tells you, in rough order of how much it matters:

Why this matters more than any single dump

Vendor diagnostics run short synthetic tests. They are good at catching components that have failed outright and poor at catching components that fail intermittently - which is most of the interesting cases. A passing diagnostic on a machine that crashes weekly is not a contradiction, it is a predictable limitation of the test.

What a support conversation cannot easily dismiss is a documented history: thirty-eight recorded failures across four months, an accelerating rate, six distinct stop codes, and WHEA entries clustering before each one. That is a pattern no short test would catch and no reimage will fix, and it shifts the conversation from have you tried reinstalling to which part gets replaced.

Build the timeline early, keep it, and add to it. The single most common mistake in this whole area is reinstalling Windows to fix a hardware fault, which destroys the only evidence you had.

Frequently asked

Reliability Monitor is empty or barely populated. Is something wrong?

It depends on the Reliability Analysis scheduled task running, and that occasionally gets disabled by optimisation utilities or on heavily customised installs. Event Viewer and the PowerShell queries read the underlying logs directly, so they still work even when Reliability Monitor shows nothing. If you want it back, look for the RACAgent task under Task Scheduler in the Microsoft Windows RAC folder.

How far back does the System log go?

Until it fills and starts overwriting - by default a few weeks to a few months, depending on how noisy the machine is. If you are diagnosing something intermittent, raise the log size early: in Event Viewer, right-click the System log, choose Properties, and increase the maximum size to something like 100 MB. That costs nothing and preserves history you will want later.

I have Kernel-Power 41 events but no BugCheck 1001. What does that mean?

The machine stopped without writing a dump. That happens with a genuine power interruption, a hard lock where the kernel never regained enough control to write anything, or a fault severe enough to kill the machine outright. It is a harder failure mode than an ordinary blue screen and leans toward power delivery or hardware. If the machine is on a desktop with no power interruptions to explain it, treat repeated bare 41s as a significant finding.

Should I clear the logs to start fresh?

No. The history is the asset. If you want a clean view of whether a fix worked, note the timestamp when you made the change and filter from there - the PowerShell queries above take a StartTime for exactly that. Clearing logs throws away the trend data that makes the case, and it cannot be recovered.