livekd no longer working on Windows 11 25H2

[akraus1]

After updating from Windows 11 23H2 to Windows 11 25H2 livek.exe did stop working.
Is this a known issue?

C:\tmp\WinDbg_1.2601.12001.0_x64\amd64>livekd64.exe      

LiveKd v5.63 - Execute kd/windbg on a live system
Sysinternals - www.sysinternals.com
Copyright (C) 2000-2020 Mark Russinovich and Ken Johnson


Exiting LiveKd.

I have tried to disable

• Core isolation
• Defender Tamper Protection
• Defender Realtime scanning.

None of the these did work.

Some AI response did ask for

bcdedit /debug on

but that did also change nothing. Is livekd no longer supported on this OS?

Or is

kd -kl

the intended replacement which is natively supported by kd.exe?

C:\tmp\WinDbg_1.2601.12001.0_x64\amd64>kd -kl
 
************* Preparing the environment for Debugger Extensions Gallery repositories **************
   ExtensionRepository : Implicit
   UseExperimentalFeatureForNugetShare : true
   AllowNugetExeUpdate : true
   NonInteractiveNuget : true
   AllowNugetMSCredentialProviderInstall : true
   AllowParallelInitializationOfLocalRepositories : true
   EnableRedirectToChakraJsProvider : false

   -- Configuring repositories
      ----> Repository : LocalInstalled, Enabled: true
      ----> Repository : UserExtensions, Enabled: true

>>>>>>>>>>>>> Preparing the environment for Debugger Extensions Gallery repositories completed, duration 0.000 seconds

************* Waiting for Debugger Extensions Gallery to Initialize **************

>>>>>>>>>>>>> Waiting for Debugger Extensions Gallery to Initialize completed, duration 0.016 seconds
   ----> Repository : UserExtensions, Enabled: true, Packages count: 0
   ----> Repository : LocalInstalled, Enabled: true, Packages count: 46

Microsoft (R) Windows Debugger Version 10.0.29507.1001 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

Connected to Windows 10 26100 x64 target at (Wed Mar 11 07:07:58.234 2026 (UTC + 1:00)), ptr64 TRUE

************* Path validation summary **************
Response                         Time (ms)     Location
Deferred                                       srv*c:\Symbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: srv*c:\Symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 10 Kernel Version 26100 MP (20 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Edition build lab: 26100.1.amd64fre.ge_release.240331-1435
Kernel base = 0xfffff801`c0c00000 PsLoadedModuleList = 0xfffff801`c1af5040
Debug session time: Wed Mar 11 07:07:59.424 2026 (UTC + 1:00)
System Uptime: 0 days 0:39:16.059
lkd> !process 4 0 
Searching for Process with Cid == 4
Type information missing error for PspMemoryReserveObjectTypes
Type information missing error for PspMemoryReserveObjectTypes
PROCESS ffffb102706c7040
    SessionId: none  Cid: 0004    Peb: 00000000  ParentCid: 0000
    DirBase: 001ae000  ObjectTable: ffffdc8b13262400  HandleCount: 5655.
    Image: System

 

[ChatGPT]

Yes — I would treat this as very likely a compatibility/support gap, not something you misconfigured.
A few important points:

• LiveKd has not been updated in a long time. Microsoft’s Sysinternals page still lists LiveKd v5.63, published April 28, 2020.
• That same page describes LiveKd as an older utility layered on top of Debugging Tools for Windows, not something that appears to have been actively revised for the newest Windows 11 kernel changes.
• I do not see Microsoft listing a specific “LiveKd broken on Windows 11 25H2” entry in the public Windows 11 25H2 known/resolved issues pages I checked.

So the short answer is:

Likely answer​

Yes, this is plausibly a known practical issue, but not a publicly documented Microsoft “known issue” with an official fix.
More precisely: LiveKd appears effectively outdated for current Windows 11 builds such as 25H2, and the behavior you show — immediate Exiting LiveKd. — is consistent with a tool that can no longer initialize correctly against the newer OS/kernel protections or internals.

Why your changes probably did not help​

The things you already tried were reasonable:

• Core isolation
• Defender tamper protection
• Defender real-time scanning
• bcdedit /debug on

But kernel debugging boot settings are not the same thing as LiveKd’s local live-dump mechanism, so bcdedit /debug on would not necessarily fix a LiveKd startup failure. That is an inference based on how LiveKd is documented versus how Windows kernel debugging is configured.

What I would recommend instead​

1. Try current WinDbg live-kernel features directly​

Microsoft notes that newer WinDbg/KD have their own live kernel debugging capability on newer Windows versions. LiveKd historically added extra convenience/features, but the built-in debugger path is the more likely supported route today.

2. Test with the latest debugger package​

If you have not already, try with the newest WinDbg Preview / current Debugging Tools for Windows, rather than relying on an older debugger folder beside livekd64.exe.

3. Check whether VBS / HVCI is still effectively active​

Even if “Core isolation” is toggled off in the UI, some virtualization-based security settings can still remain enforced by policy or firmware state after upgrades. That said, given the age of LiveKd, I would still suspect tool incompatibility first.

4. Capture more diagnostics​

Try launching from an elevated console and note:

livekd64.exe -?
livekd64.exe -k "C:\Program Files\WindowsApps\Microsoft.WinDbg_...\amd64\kd.exe"

Also confirm:

• exact Windows build: winver
• whether this is retail 25H2 or an Insider/Canary/Dev build
• whether Memory integrity is really off after reboot
• whether Hyper-V / VBS features are enabled

Practical conclusion​

If your workflow depends on LiveKd specifically, I would currently assume:

• 23H2 worked
• 25H2 changed enough that LiveKd 5.63 no longer works reliably
• there may be no fix unless Microsoft/Sysinternals updates LiveKd, and the public download page does not show a newer release.

If you want, I can help you with either of these next steps:

1. build a modern replacement workflow using current WinDbg on 25H2, or
2. give you a targeted checklist to verify whether this is blocked by VBS/HVCI/hypervisor state on your machine.