LiveKernelEvent 193

Question

LiveKernelEvent 193

NS 0

System:

GPU: MSI RTX 5090 Lightning Z
CPU: AMD Ryzen 7 9800X3D
Motherboard: ASUS ROG Crosshair X870E Apex
RAM: 32GB DDR5
PSU: Cooler Master X Mighty 2000 (80 Plus Platinum, ATX 3.1)
OS: Windows 11 Pro
NVIDIA Driver: 591.86

NO OVERCLOCKS

Issue:

I am experiencing intermittent LiveKernelEvent 193

The latest event occurred while NOT gaming. Windows remained responsive. There was no BSOD, reboot, or full system freeze.

I have observed these issues across multiple NVIDIA driver versions, not just 591.88.

WinDbg output from the latest dump:

PROCESS_NAME: dwm.exe
MODULE_NAME: dxgkrnl
IMAGE_NAME: dxgkrnl.sys
FAILURE_BUCKET_ID: LKD_0x193_dxgkrnl!DxgCreateLiveDumpWithWdLogs2
Bugcheck: VIDEO_DXGKRNL_LIVEDUMP (193)
Arg1: 0x80e

Relevant output:

PROCESS_NAME: dwm.exe

MODULE_NAME: dxgkrnl

IMAGE_NAME: dxgkrnl.sys

FAILURE_BUCKET_ID:

LKD_0x193_dxgkrnl!DxgCreateLiveDumpWithWdLogs2

Troubleshooting already attempted:

Clean Windows installation
DDU driver cleanup
Multiple NVIDIA driver versions tested
Different display configurations tested
Long gaming sessions can sometimes run for hours without issue

Has anyone seen LiveKernelEvent 193 (0x80e) involving dwm.exe and dxgkrnl on RTX 50-series systems, and is there a known root cause or additional debugging method that could narrow this down further?

Description

A problem with your hardware caused Windows to stop working correctly.

Problem signature

Problem Event Name: LiveKernelEvent

Code: 193

Parameter 1: 80e

Parameter 2: ffffa88aab6e2080

Parameter 3: ffff888460c175a0

Parameter 4: 0

OS version: 10_0_26200

Service Pack: 0_0

Product: 256_1

OS Version: 10.0.26200.2.0.0.256.48

Locale ID: 1033

Files that help describe the problem

WATCHDOG-20260602-1827.dmp

sysdata.xml

WERInternalMetadata.xml

memory.csv

sysinfo.txt

WERInternalRequest.xml

5: kd> !analyze -v

Loading Kernel Symbols

...............................................................

................................................................

..................................

Loading User Symbols

PEB is paged out (Peb.Ldr = 000000b9`79c38018). Type ".hh dbgerr001" for details

Mini Kernel Dump does not contain unloaded driver list

                   Bugcheck Analysis                                    *

VIDEO_DXGKRNL_LIVEDUMP (193)

Livedumps triggered by dxgkrnl when a problem is detected.

(This code can never be used for a real BugCheck; it is used to identify live dumps.)

Arguments:

Arg1: 000000000000080e, Reason Code.

100 Internal

Arg2: ffffa88aab6e2080, Reserved.

Arg3: ffff888460c175a0, Reserved.

Arg4: 0000000000000000, Reserved.

Debugging Details:

Mini Kernel Dump does not contain unloaded driver list

KEY_VALUES_STRING: 1

Key  : Analysis.CPU.mSec

Value: 812

Key  : Analysis.Elapsed.mSec

Value: 837

Key  : Analysis.IO.Other.Mb

Value: 0

Key  : Analysis.IO.Read.Mb

Value: 1

Key  : Analysis.IO.Write.Mb

Value: 0

Key  : Analysis.Init.CPU.mSec

Value: 328

Key  : Analysis.Init.Elapsed.mSec

Value: 45784

Key  : Analysis.Memory.CommitPeak.Mb

Value: 94

Key  : Analysis.Version.DbgEng

Value: 10.0.29547.1002

Key  : Analysis.Version.Description

Value: 10.2602.27.2 amd64fre

Key  : Analysis.Version.Ext

Value: 1.2602.27.2

Key  : Bugcheck.Code.LegacyAPI

Value: 0x193

Key  : Bugcheck.Code.TargetModel

Value: 0x193

Key  : Dump.Attributes.AsUlong

Value: 0x18

Key  : Dump.Attributes.KernelGeneratedTriageDump

Value: 1

Key  : Failure.Bucket

Value: LKD_0x193_dxgkrnl!DxgCreateLiveDumpWithWdLogs2

Key  : Failure.Hash

Value: {f51452f1-290a-6a1b-5cf3-c8f949ad9c33}

BUGCHECK_CODE: 193

BUGCHECK_P1: 80e

BUGCHECK_P2: ffffa88aab6e2080

BUGCHECK_P3: ffff888460c175a0

BUGCHECK_P4: 0

FILE_IN_CAB: WATCHDOG-20260602-1827.dmp

DUMP_FILE_ATTRIBUTES: 0x18

Kernel Generated Triage Dump

Live Generated Dump

FAULTING_THREAD: ffffa88aab6e2080

PROCESS_NAME: dwm.exe

STACK_TEXT:

ffffe08acc207220 fffff80650c071d8 : ffffa88aaee65d00 0000000000000000 0000000000000000 000000000000080e : watchdog!WdpDbgCaptureTriageDump+0xe6

ffffe08acc207290 fffff80650c03bf8 : ffff888460c17500 0000000000000193 000000000000080e ffff8884779a6008 : watchdog!WdDbgReportRecreate+0x108

ffffe08acc2072f0 fffff80650ff63b2 : ffff888460c175a0 ffffe08acc2074e0 0000029c6824d57c 00000000c000000d : watchdog!WdDbgReportCreate+0x58

ffffe08acc207360 fffff80650ff635b : ffff888460c175a0 ffffe08acc2074e0 00000000c000000d fffff8069a15a3d2 : dxgkrnl!DxgCreateLiveDumpWithWdLogs2+0x4a

ffffe08acc2073d0 fffff80650f4dfb6 : 0000000500000000 ffffa88aab6e2080 ffffa88aab6e2080 000000b97a07f910 : dxgkrnl!DxgCreateLiveDumpWithWdLogs+0x2b

ffffe08acc207420 fffff806bf4bc558 : ffffa88aab6e2080 0000000000003670 ffffa88aab6e2080 0000029c68ecde20 : dxgkrnl!NtDxgkPinResources+0x76

ffffe08acc207460 00007ffae2b33f04 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x28

000000b97a07f148 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x00007ffa`e2b33f04

SYMBOL_NAME: dxgkrnl!DxgCreateLiveDumpWithWdLogs2+4a

MODULE_NAME: dxgkrnl

IMAGE_NAME: dxgkrnl.sys

IMAGE_VERSION: 10.0.26100.8457

STACK_COMMAND: .process /r /p 0xffffa88aab670080; .thread /r /p 0xffffa88aab6e2080 ; kb

BUCKET_ID_FUNC_OFFSET: 4a

FAILURE_BUCKET_ID: LKD_0x193_dxgkrnl!DxgCreateLiveDumpWithWdLogs2

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

FAILURE_ID_HASH: {f51452f1-290a-6a1b-5cf3-c8f949ad9c33}

Followup: MachineOwner

0 comments

3 answers

Your answer

Answer 1

David-M 114.2K Independent Advisor

Thanks for the clarifications.

Knowing your Samsung 990 PRO is in M.2_1 completely rules out any accidental PCIe lane splitting.

However, that screenshot and your description of it jumping between 2.0 and 5.0 every second is a huge clue. While it's normal for a GPU to drop to lower PCIe generations at idle to save power, rapidly cycling between Gen 2 and Gen 5 every single second means the PCIe link is unstable or caught in a power-state loop. This rapid switching is exactly what trips the DirectX Watchdog, leading to that random Live Kernel Event 193.

What I recommend is the following:

1 = Force PCIe Gen 4 in the BIOS:

The RTX 5090 on an X870E board pushes PCIe Gen 5 to the limit, and early motherboard revisions can have signal stability issues.

In your ASUS BIOS (Advanced Mode), change the main PCIe Slot Link Speed from "Auto" or "Gen 5" to Gen 4. You won't lose any gaming performance, but it might drastically improve signal stability.

2 = Use the ASUS-specific Chipset Driver:

Try uninstalling the generic AMD driver and installing the one directly from the official ASUS support page for your ROG Crosshair X870E Apex. Motherboard vendors sometimes tweak power-management tables specifically for their board's electrical layout.

3 = Double-check the physical fit:

Since you just moved that massive 5090 into a new board:

Make sure it isn't sagging or straining the new PCIe slot pins.
Unplug and firmly re-seat the 16-pin power cable until it clicks completely. A tiny voltage drop on a sense pin during power transitions can trigger this exact dump.

Let me know how it goes.

Feel free to ask any questions you may have.

NS 0 Reputation points

2026-06-02T20:08:16.2366667+00:00

I have actually tried PCIe GEN 4 last week and still errored. I will reinstall the ASUS specific Chipset Driver and give it a go. I´m kinda thinking it might be the PCIe slot. If non of these help, I might try another MOBO to rule out the Apex. I have 1 last question tho. Do you think G-Sync in any way can effect this Problem? Maybe I´m remembering it worng, but I errored twice today. once 10min in a game, 2nd time in idle windows opening and closing things. all within 1h. Then i turned off Gsync, no error. I´m gaming for over an hour now. This setup, was stable for 3 days prior to me adding a new Monitor today, thus why i tried Gsync.
David-M 114.2K Reputation points Independent Advisor

2026-06-02T20:23:29.2866667+00:00

Thanks for the details.

Yes, G-Sync combined with a new monitor can absolutely cause this exact issue.

I did a quick search online regarding this specific behavior, and it turns out that G-Sync, especially when set to windowed mode/borderless windowed, forces the GPU to rapidly cycle power states during basic desktop animations.

Since your motherboard is likely 100% fine, here is how to make G-Sync play nice without crashing:

1 = Restrict G-Sync to Full Screen Only:

G-Sync in windowed mode is notoriously buggy with the Windows desktop. In the Nvidia Control Panel (Set up G-SYNC), make sure it is set to "Enable for full screen mode" only.

2 = Change Nvidia Power Management Mode:

In "Nvidia Control Panel > Manage 3D Settings", set Power management mode to "Prefer maximum performance". This prevents the GPU from aggressively downclocking to Gen 2 on the desktop, stabilizing the link.

Let me know how it goes.

Feel free to ask any questions you may have.
NS 0 Reputation points

2026-06-02T20:26:40.8033333+00:00

fun fact, i was in wondowed mode and split the game across 2 monitors to see the difference in monitor quality. i hope this madness is the true cause. for now i will turn gsync just off. i just wish to have a stable system again. thank you very much David, hopefully i never have to come here again D,:
David-M 114.2K Reputation points Independent Advisor

2026-06-02T20:31:09.6233333+00:00

Glad to help.

If you have any questions, don't hesitate to ask.
NS 0 Reputation points

2026-06-05T15:44:27.5433333+00:00

Hi David, just a quick update and have this issue documented for maybe future users. after i turned off gsync all my issues were gone. im on day 4 now, at least 6h daily use, no errors. i had an error 15-30min into a game before, so im feeling confident. thanks again ^^

Answer 2

David-M 114.2K Independent Advisor

Hi. I'm David, and I'm happy to help you.

Since you've already done a clean Windows install and the crash only happens at idle, it's highly likely a power state or compatibility bug with this specific hardware configuration.

Two quick questions to narrow this down:

1 = Is your Asus motherboard running the latest BIOS version?

If you're not sure, please share a screenshot of your system information.

Press "Windows + R", type msinfo32 and press Enter.

Maximize the window and use the shortcut "Windows + Shift + S" to use the screenshot tool.

2 = Have you updated your AMD chipset drivers? If yes, did you get them directly from AMD, or did you use Windows Update, Asus software, or third-party software?

Looking forward to your reply.

NS 0 Reputation points

2026-06-02T18:00:20.6133333+00:00

Hi David, thank you for helping! Games also do crash. It´s very random. i leave the game open for 8H and nothing happens, then other times i play for 20 min and it crashes with the same error. i tried 3 different mobo bioses. 1512, very old, 22XX, i dont remember exactly anymore, and this one. the Bios makes no difference. Also AMD chipset driver is from the official download. this system was stable for 3 months. i changed the mobo and a monitor config, from 3 to 2 monitors, and this started to happen, could be completly unrelated too.
David-M 114.2K Reputation points Independent Advisor

2026-06-02T18:15:17.6666667+00:00
Thanks for the clarifications.

Also AMD chipset driver is from the official download.

Which official download are you referring to? Is it from the AMD or Asus website? This can make a big difference because for some motherboards, the manufacturer's driver is more suitable than AMD's own.

What method did you use to clean install Windows? Did you perform a clean installation using an installation media (USB flash drive), completely erasing the system drive before reinstalling? Or did you reset the PC, choosing to remove everything?

When you say "No Overclocks", does this include AMD EXPO being disabled in the BIOS?

Looking forward to your reply.
NS 0 Reputation points

2026-06-02T18:20:37.2966667+00:00
Thank you for youre reply.

Windows reinstall:

USB installer

Delete all partitions

Install fresh

AMD Driver:

amd_chipset_software_8.05.04.516

its from AMD website

No overclocks. this Error happened on jedec, all stock settings aswell.
David-M 114.2K Reputation points Independent Advisor

2026-06-02T19:17:22.8266667+00:00

Thanks for the clarifications.

That rules out Windows and RAM completely.

Before we jump into changing BIOS settings, I noticed a very specific layout quirk in the ROG Crosshair X870E Apex specifications regarding Ryzen 9000 CPUs that we should double-check:

Are you using any M.2 NVMe SSDs? If so, do you know which specific slots they are installed in?

According to the ASUS manual, if a drive is populated in either the M.2_2 or M.2_3 slots, the motherboard automatically splits the PCIe lanes and drops your main GPU slot from x16 down to x8 mode. On Gen 5 platforms, this heavy lane-splitting can sometimes trigger signal instability or timing mismatches with a massive card like the 5090.

Looking forward to your reply.
NS 0 Reputation points

2026-06-02T19:36:09.8733333+00:00

My SSD is installed in M.2_1, the primary slot above the GPU under the motherboard heatsink.

The SSD is Samsung 990 PRO 2TB

on GPU-Z i can also verify 16 5.0.

However a couple days ago I saw this, see screenshot.

it jumped from 2.0 to 5.0 every second ish

Answer 3

LiveKernelEvent 193 with bug check VIDEO_DXGKRNL_LIVEDUMP (0x193) indicates that the DirectX graphics kernel (dxgkrnl.sys) detected a problem and proactively triggered a live dump via the watchdog subsystem, without forcing a full bug check or reboot.

From the documentation:

VIDEO_DXGKRNL_LIVEDUMP (0x193) is a live dump identifier only; it is not a traditional crash bug check.
Parameter 1 is a reason code; for this code the documented value is 0x100 (Internal). In the dump shown, Arg1 is 0x80e, which is still a dxgkrnl-originated reason but not further documented in the provided material.
The dump is created by dxgkrnl!DxgCreateLiveDumpWithWdLogs2 in cooperation with the watchdog (watchdog!WdpDbgCaptureTriageDump), exactly as seen in the stack.

What this means for the system:

Windows and the desktop (dwm.exe) can remain responsive because this is a live kernel triage dump, not a fatal stop error.
The event text “A problem with your hardware caused Windows to stop working correctly” is generic WER wording for LiveKernelEvents and does not by itself prove a failing component.

Next technical steps, based on the available guidance:

Use WinDbg to dig deeper into the dump
- The documentation explicitly recommends using !analyze for VIDEO_DXGKRNL_LIVEDUMP to get more detail on the root cause.
- In the current analysis, only the high-level bucket is visible. To go further, use additional debugger commands on the same dump:
  - !analyze -v (already run) to confirm the faulting module and parameters.
  - k / kb / kv to walk the stack around dxgkrnl!NtDxgkPinResources and see which driver stack is involved at the time of the dump.
  - lmv on the display miniport driver (for example, the NVIDIA kernel driver module) to inspect version and timestamp, as is recommended for TDR-style graphics issues.
Treat it similarly to early-stage TDR/graphics stability issues The VIDEO_TDR_TIMEOUT_DETECTED (0x117) guidance is the closest documented analogue for GPU/driver/graphics-pipeline problems that do not always hard-crash the system. The same classes of root causes apply:
- Display driver issues across versions.
- Hardware factors affecting GPU operation (power, thermals, memory, motherboard/PCIe path).
- System load patterns (visual effects, background apps) that stress the graphics stack.
Recommended checks from that guidance that are applicable here:
- Ensure the display driver is fully up to date and WHQL-signed for the current OS build.
- If a particular driver version is repeatedly implicated in dumps (via lmv and stack traces), consider rolling back to a known-stable version or testing a newer one when available.
- Verify that all graphics-related components (DirectX runtime, graphics-intensive apps) are fully updated.
- Confirm that the new hardware (RTX 50-series GPU and X870E platform) is certified/compatible for the specific Windows 11 build in use.
Use Event Viewer alongside the dump
- For VIDEO_TDR_TIMEOUT_DETECTED and related GPU issues, the documentation recommends checking the System log for additional errors around the same timestamp (Display, dxgkrnl, nvlddmkm, Kernel-Power, etc.).
- Correlating those events with the live dump time can help determine whether this is:
  - A transient driver recovery.
  - A repeated pattern tied to a specific application or power state.
If reproductions become consistent
- Set breakpoints in the relevant code path and single-step toward the faulting code, as suggested for graphics bug checks. This is only practical if the issue can be triggered reliably.
- Capture additional dumps (including full or kernel memory dumps) to get more context than the triage live dump.
Basic stability checks (non-destructive) While the system is not hard-crashing, the same general troubleshooting steps used for TDR issues are still applicable:
- Use Safe Mode to see if the issue disappears when only minimal drivers/services are loaded. If LiveKernelEvent 193 does not occur in Safe Mode, that strongly points to a third-party driver or higher-level graphics component.
- Run Windows Memory Diagnostics to rule out marginal RAM issues that can manifest under GPU/graphics load.
- Run OEM or third-party hardware diagnostics for GPU and motherboard if available.

Summary:

LiveKernelEvent 193 with VIDEO_DXGKRNL_LIVEDUMP is a dxgkrnl-triggered live dump, not a fatal bug check.
The official guidance is to use WinDbg (!analyze, stack inspection, lmv) to identify the responsible driver/module and then apply the same classes of troubleshooting used for VIDEO_TDR_TIMEOUT_DETECTED: driver updates/rollbacks, hardware and compatibility checks, and correlation with Event Viewer.
The provided context does not document a specific known root cause for reason code 0x80e on RTX 50-series; further analysis of additional dumps and system logs is required to narrow it down.

References:

Share via

LiveKernelEvent 193

3 answers

Your answer