LiveKernelEvent: Hardware Errors Without a Blue Screen

You open Reliability Monitor, find a red entry marked Hardware error with a problem code like LiveKernelEvent 141, and nothing else. The machine did not blue screen. There is no stop code to look up. Most of what you will find online about these codes is community guesswork, and it contradicts itself - so this page is explicit about which parts are solid and which are not.

Updated 2026-07-28

What a LiveKernelEvent actually is

Windows can capture a live dump: a snapshot of kernel memory taken while the system keeps running. Something went wrong badly enough to be worth recording, but not badly enough to require stopping the machine - so Windows writes the evidence and carries on.

That is what these entries are. A component reported a fault, Windows captured state, recovery succeeded, and you kept working. The entry in Reliability Monitor is the only outward sign.

The practical consequence is that these are early warnings. A machine producing live kernel events is telling you something is wrong before it starts producing blue screens. That is a genuinely useful window, and almost nobody uses it because the entries look inscrutable.

An honest note about the code numbers

Read this before trusting any code list

Microsoft does not publish a complete public reference mapping LiveKernelEvent codes to meanings, the way it does for bugcheck codes. The lists circulating on forums and content farms are assembled from observation, they disagree with each other, and several widely-repeated entries appear to be guesses that got copied.

What follows covers the codes that can be corroborated against documented Windows behaviour. Where something is inference rather than documentation, this page says so.

The more reliable approach is to ignore the code as a lookup key and read the dump instead. The dump contains what actually happened; the code is a label whose meaning you cannot verify.

The codes you are most likely to see

Code	What it corresponds to	Confidence
117	A display driver timeout - the GPU did not respond within the deadline and Timeout Detection and Recovery reset it. The same underlying event as the recoverable form of VIDEO_TDR_FAILURE, and it usually appears alongside Event ID 4101 in the System log.	Solid - the correspondence to TDR behaviour is consistent and checkable against the event log.
141	A GPU engine hang - the graphics hardware stopped responding and could not be recovered the way a 117 was. Widely associated with genuine GPU hardware trouble rather than driver bugs, particularly when it repeats.	Reasonable - the display-hardware association is well established in practice, though the exact internal meaning is not publicly documented.
124	A hardware error reported through WHEA, captured live rather than as a stop. Effectively the non-fatal sibling of bugcheck 0x124. Check the System log for WHEA-Logger entries at the same timestamp.	Solid - it corresponds to the WHEA reporting path and correlates with WHEA-Logger events.
Others	Various codes appear - 144, 193, 1a8 and more. Published explanations for these are inconsistent and this page will not add to the guesswork.	Not established. Read the dump.

One pattern is worth knowing: several LiveKernelEvent codes share numbers with the bugcheck code for the equivalent fatal condition. 117 and 124 both line up that way. It is a useful heuristic and not a rule, so treat it as a starting hypothesis to check against the event log rather than as an answer.

Finding and reading the dump

This is the part that turns a mystery code into information. Live dumps are written to:

C:\Windows\LiveKernelReports\

You will find subfolders per event type, containing .dmp files. List them with timestamps:

Get-ChildItem -Path C:\Windows\LiveKernelReports -Recurse -Filter *.dmp |
  Select-Object LastWriteTime, Length, FullName |
  Sort-Object LastWriteTime -Descending |
  Format-Table -AutoSize

Open one in WinDbg exactly as you would a crash dump and run !analyze -v. The output names modules and shows a stack the same way. If the event was WHEA-related, note the error record address and run !errrec <address> - that names the reporting hardware component in plain language, which is far more use than any code table.

The dump reading guide applies unchanged here.

Reading them in context

A live kernel event on its own is a data point. What makes it meaningful is what surrounds it, so pull the window around each one:

$t = Get-Date '2026-07-20 14:30'
Get-WinEvent -FilterHashtable @{LogName='System'; StartTime=$t.AddMinutes(-10); EndTime=$t.AddMinutes(10)} |
  Sort-Object TimeCreated |
  Select-Object TimeCreated, ProviderName, Id, LevelDisplayName |
  Format-Table -AutoSize

What to look for:

Event ID 4101 from Display - confirms a display driver timeout and recovery, which corroborates a 117.
WHEA-Logger entries - hardware errors reported directly by the platform. See Event 17.
Kernel-Power 41 - if one appears shortly after, the live event was a precursor to something worse.
Disk or storage errors - narrows a vague event to a subsystem.

What to actually do about them

The response depends entirely on rate and on what else is in the log.

One or two, months apart, nothing else around them. Note them and move on. A single recovered fault is not a problem to solve.

A steady trickle correlating with display activity. Treat it as the recoverable form of a display driver problem. Clean-install the graphics driver with DDU, check GPU temperatures including memory junction if the card reports it, and disable Multi-Plane Overlay as a test. The VIDEO_TDR_FAILURE page covers this in full.

Repeated 141s, or events with WHEA entries alongside. This is the case that matters. Repeated GPU engine hangs that survive a clean driver install, especially with artefacts or with WHEA errors at the same timestamps, point at hardware. Test the card in another machine if you can - that single test is more conclusive than anything else available.

An accelerating rate. Regardless of code, this is the signal worth acting on. Live kernel events increasing week over week are a component degrading, and the useful time to act is while it is still recovering rather than after it stops recovering.

Why this is worth your attention

Live kernel events are the stage before blue screens. A machine that recovers from twenty of these a week is a machine whose recovery mechanisms are being exercised hard - and those mechanisms have limits. Documenting them now, while the machine still works, is how you build the crash history that supports a warranty claim later.

Frequently asked

My PC never crashed. Why is Reliability Monitor showing a hardware error?

Because the fault was recovered. Windows detected a problem, captured a live dump for diagnosis, and the affected component recovered - so nothing interrupted you beyond perhaps a brief screen flicker. The entry is a record of something that went wrong and was handled. That is not nothing, but it is also not the same as a crash, and one isolated entry does not need action.

Is LiveKernelEvent 141 always a dying graphics card?

No, though it is associated with GPU hardware trouble often enough that it deserves attention. A single 141 can follow a driver problem, an unstable overclock, or a thermal spike. What shifts it toward hardware is repetition: 141s that keep coming after a clean driver install, at stock clocks, with good temperatures - especially alongside visual artefacts or WHEA entries. Test the card in another machine before spending money.

Can I stop Windows collecting these?

You could suppress the reporting, and you should not. The collection costs you essentially nothing - a dump file and a log entry - and it is the only visibility you have into faults that are currently being recovered. Turning it off does not stop the faults happening; it stops you knowing. It also removes the evidence that a warranty conversation would rest on.

The LiveKernelReports folder is large. Can I delete it?

Yes, the dump files themselves are safe to delete once you have finished with them - they are diagnostic artefacts, not system files. Copy anything you might need for a support conversation first. Disk Cleanup will also clear them under system error memory dump files. Note that deleting the dumps does not remove the Reliability Monitor entries, which live in the event log.

Why is there so little official documentation on these codes?

Live dump collection is largely an internal diagnostic mechanism - it exists so that telemetry and support engineers can analyse recovered faults, not as a user-facing troubleshooting feature. Microsoft documents bugcheck codes thoroughly because users see them on a blue screen and need to act. Live kernel events were never meant to be read by hand, which is why the code table is not published and why so much of what circulates about them is inference.