LiveKernelEvent 141 in Windows 11 means a display engine stopped responding within the expected time. You may discover it after a game closes, the screen freezes, or Windows briefly recovers from a graphics problem. The report narrows the investigation to a graphics timeout, but it does not prove that your GPU is defective.
The useful next step is to connect the event with what the PC was doing. A failure confined to one game, a problem that began after a driver update, and instability across several applications need different tests. Save the report before changing settings so you can compare later failures with the original.
What Code 141 Establishes
Microsoft identifies 0x141 as VIDEO_ENGINE_TIMEOUT_DETECTED in its live-dump code documentation. The code is used for a live dump rather than a normal blue-screen bug check.
Windows can collect a live dump while the operating system continues running. That explains why Reliability Monitor can show a hardware-error entry even when you did not see a blue screen. A separate crash or restart may also occur, but code 141 alone does not explain every event that happened afterward.
The “Hardware error” label is a category in the report, not a diagnosis of a failed component. Driver behavior, an application workload, unstable tuning, and physical hardware are possible areas to investigate. A driver name in an analysis is another clue, not an automatic instruction to replace that manufacturer’s graphics card.
Open the Event and Save Its Details
- Press Windows + R.
- Enter
perfmon /reland press Enter. - Select the day that matches the freeze or application failure.
- Select the relevant Windows hardware-error entry.
- Open View technical details.
Several failures can appear on the same day. Match the timestamp and description to the incident you remember instead of assuming the first red marker is the relevant one.
In the details, look for Problem Event Name: LiveKernelEvent and Code: 141. Keep the remaining signature fields too. They can help support staff distinguish reports that share the same headline code.
Copy the available details or take a screenshot. Record the approximate time, application, visible symptom, GPU model, driver version, and any recent change. Remove identifying information before posting a report publicly.
A single old entry without a repeat failure does not justify a disruptive repair. Concentrate on current, recurring incidents and whether they interrupt your work.
Use the Trigger to Choose a Test
The following observations help decide where to investigate. None proves a cause on its own.
| When the failure occurs | A useful next test | What the result can tell you |
|---|---|---|
| Only in one game or application | Update that application, verify its files where supported, and compare another workload | Whether the failure follows a particular application |
| Immediately after a graphics-driver update | Test a supported previous driver version | Whether the newer driver is associated with the regression |
| After overclocking or undervolting | Remove the custom tuning and reproduce the original task | Whether the tuned configuration contributes to instability |
| Across games, video playback, and other graphics tasks | Compare stock settings and a suitable driver, then inspect cooling and hardware | Whether the problem extends beyond one application |
| Only after sleep, docking, or changing displays | Reproduce that transition with a simpler display arrangement | Whether the trigger is a transition rather than sustained GPU load |
Change one variable at a time. If you update the driver, remove tuning, disable overlays, and change power settings together, an improvement will not tell you which change mattered.
A Failure Limited to One Application
Start with the application and the workload that triggers it. Install its current update and check its official support notes for known graphics problems. For a game launcher with a file-verification function, use that before reinstalling the whole game.
Temporarily disable a recording overlay or graphics modification used by that application, then repeat the same scene or task. Restore the setting if it makes no difference. An overlay is a test variable, not a confirmed cause simply because it is installed.
For browser-only failures, compare the same video or page in another current browser. Testing the browser’s hardware-acceleration setting can help establish whether its GPU path is involved, but leaving acceleration off is a workaround rather than proof that the GPU is healthy or faulty.
An unrelated game completing successfully is useful evidence. It does not guarantee that every graphics workload is stable.
A Failure That Began After a Driver Update
Record the installed version before changing it. In Device Manager > Display adapters, open the GPU’s properties and check the Driver tab.
If Roll Back Driver is available, it can restore the previous installed driver. If it is unavailable, obtain a compatible earlier package from the graphics-card or PC manufacturer’s official support site. Avoid third-party driver-download sites and automatic “driver repair” utilities.
On a laptop with integrated and dedicated graphics, the PC manufacturer’s recommended packages may be the appropriate starting point. Do not disable the integrated GPU just because a game normally uses the dedicated one; hybrid display arrangements can depend on both.
Repeat the original task after the driver change and note whether a new code 141 event appears. A clean installation can be worth considering when installation problems or repeated regressions point toward the driver, but repeated removal without a changed result adds little evidence.
A Failure After Tuning Changes
Remove custom GPU overclocking, undervolting, or automatic-tuning settings using the utility that applied them. Check that another utility is not restoring a profile at startup. Test with the same application afterward.
Do not respond by raising voltage or guessing at power limits. The purpose is to establish a stable baseline, not to find a more aggressive configuration while the PC is already failing.
An interrupted NVIDIA tuning scan is also a different problem from a confirmed display timeout. Use NVIDIA Automatic Tuning Not Working when the scan itself is failing; do not treat that symptom alone as evidence of damaged graphics hardware.
If you also have unrelated crashes after CPU or RAM tuning, remove those custom changes selectively and retest. Loading every BIOS default can change boot and security settings, so a graphics error alone is not a reason to reset the entire firmware configuration.
When the Problem Appears Across Several Workloads
Broader instability makes cooling, power delivery, and the physical installation more relevant, particularly after a hardware change. Keep the driver and tuning tests documented so a hardware check does not begin from guesswork.
Observe whether the failure occurs only when the PC becomes hot, whether ventilation is obstructed, and whether fans behave abnormally. Temperature limits vary by GPU and system; one universal temperature cutoff is not a reliable diagnosis.
Stop testing if you notice a burning smell, a damaged connector, or obvious overheating. Avoid repeated stress-test crashes as a substitute for diagnosis.
For a desktop with a recently installed GPU, have the card seating and power connections checked with the PC shut down and disconnected. Follow the GPU and power-supply manufacturer’s instructions. Never open the power supply or mix modular PSU cables from different models merely because the plugs fit.
A monitor or cable problem can explain a missing picture, but it does not automatically explain the recorded display-engine timeout. Match the visible symptom to the event timestamp. If you recently changed GPU brands, Switching From NVIDIA to AMD GPU covers the installation and driver-transition checks for that situation.
Preserve a Live Dump if the Error Keeps Returning
Windows normally stores live kernel reports under:
C:\Windows\LiveKernelReports
Look for a .dmp file or a component subfolder, such as WATCHDOG, with a timestamp near the incident. You may need administrator permission. A missing file does not prove that no timeout occurred; dump collection and retention are not guaranteed for every event.
Copy an existing relevant dump before running cleanup tools. Do not delete the report simply to make Reliability Monitor look clean. Deleting diagnostic records does not repair the cause.
A technician can analyze the dump with Microsoft’s WinDbg. For readers already comfortable with the debugger, opening the dump and running !analyze -v provides a starting point. A module or failure-bucket name needs interpretation alongside the workload, driver version, and other evidence. It is not a complete diagnosis by itself.
Dump files can contain memory information. Share them through a trusted support channel rather than attaching them to a public post without considering their contents.
Avoid Registry Changes That Hide the Timeout
Some guides recommend increasing TdrDelay, disabling timeout recovery, or importing a Registry file as a universal fix. Microsoft describes these settings as driver-development controls and explicitly says end users should not manipulate them in its TDR Registry guidance.
Changing the timeout threshold does not establish why the display engine stalled. It can alter how long a freeze lasts or how recovery behaves while leaving the underlying problem unresolved. Do not make those edits simply because code 141 appears.
Similarly, an isolated graphics timeout is insufficient evidence for a factory reset, random BIOS update, or immediate GPU replacement.
Give Support a Reproducible Incident
Escalate when the same task repeatedly fails at stock settings with an appropriate driver, the problem affects several applications, or there are signs of physical damage. Laptop and prebuilt-system owners can start with the PC manufacturer; a separately purchased graphics card may need its vendor’s support.
Provide the event details, relevant dump if available, GPU and system models, driver versions tested, the task that triggers the failure, and the result of each controlled change. Distinguish a brief recovered freeze from a full shutdown or restart.
“Code 141 returned during the same game scene on two driver versions, with custom tuning removed” is more useful than “I tried everything.” A reproducible report helps support decide which component or configuration deserves the next test without asking you to repeat unrelated fixes.
