Windows 11 25H2 Kerberos Calls Hang Without Any Network Traffic

Removing the endpoint security product does not necessarily eliminate its drivers, policies, or interactions with the authentication stack, so verify that the uninstall was complete. However, reproducing the issue on another fresh machine makes it more likely that a shared factor—such as a recent Windows update, domain policy, Wi-Fi transition, firewall HA behavior, or the Kerberos TCP setting—is involved.

Build a timeline around resume/startup, network authentication, DC selection, and the first failed SSPI call. Compare an affected client with an unaffected one, including applied policies, Credential Guard state, domain-controller discovery, and TCP 88 connections. A dump captured during the hang should take priority over further packet captures because the request appears not to be leaving LSA.

The HA virtual IP and forced TCP transport are worth testing separately. If a firewall failover leaves an established Kerberos TCP session in a stale state, reconnecting Wi-Fi could reset the socket and explain why the issue temporarily disappears. During the problem, check active connections with Get-NetTCPConnection -RemotePort 88 and compare the results before and after reconnecting.

I would temporarily remove the MaxPacketSize=1 override in a controlled test as well. Forcing every Kerberos exchange onto TCP changes the failure mode and adds dependence on long-lived TCP sessions. Also check whether the affected clients are consistently resolving the same domain controller and whether the issue follows a particular firewall node or access point.

The lack of packets is an important clue, but it does not prove a system-wide deadlock. Since klist is hanging while enumerating the ticket cache, it may be blocked inside the local LSA before it ever attempts a network request. The ticket cache is held in memory, so DNS, the firewall, and the domain controllers would not necessarily be involved at that point.

Capture a full user-mode dump of lsass.exe while the machine is stuck, for example with ProcDump, and inspect the wait chains and thread stacks. That should show whether one thread is holding an LSA or authentication-package lock that other SSPI callers are waiting on. Without a dump taken during the hang, it is difficult to distinguish a genuine lock from another local failure.

The fact that ping and other non-authentication tools continue working while klist, RDP, proxy authentication, and GSSAPI applications hang points toward the local security subsystem rather than a general network outage. A clean installation reproducing it makes a damaged Windows image less likely, although policy and driver differences still need to be ruled out.

Test an official Microsoft installation with no third-party security software and as few domain policies as possible. At the moment of failure, collect an lsass dump and perform a wait-chain check on lsass.exe. If Credential Guard is enabled, LSAIso.exe may not expose all of the relevant internal state, but its presence and related event logs are still useful evidence.