Windows Server 2025 DC — LSASS handle leak identified via WinDbg — authz!AuthzpDeQueueThreadWorker
Hello All!! Im having a problem, LSASS crashes on a Windows Server 2025 Domain Controller, I identified what appears to be the root cause using WinDbg memory dump analysis. Sharing this hoping someone else has seen it or Microsoft can confirm. The Problem LSASS handle count grows continuously over time and eventually crashes with a 0xC0000005 access violation (Event ID 1015). After a reboot the cycle repeats. The growth rate correlates with authentication load and faster during peak hours, slower overnight. WinDbg Dump Analysis Captured LSASS dump at high handle count and ran !handle 0 f: Token handles: overwhelmingly dominant Everything else: negligible Every leaked token shows: GrantedAccess: 0x8 (TOKEN_QUERY only) PointerCount: overflowed to negative integer Running !findstack authz 2 shows multiple worker threads all sitting in: authz!AuthzpDeQueueThreadWorker What Was Tested And Eliminated Stopped or disabled each individually and measured handle growth rate — zero meaningful difference from any: - Antivirus (all components) - Backup software - Application services - VSS snapshots - Hardware management agents etc.. Environment OS: Windows Server 2025, fully patched with the latest updates including April LSASS update. Role: Domain Controller DNS PAM: Not active. Conclusion Token handles are opened with TOKEN_QUERY access inside authz!AuthzpDeQueueThreadWorker and never released. Reference counter overflows to negative integer. Growth rate scales directly with authentication load. Current workaround: reboots during off hours. Has anyone else seen this pattern on Windows Server 2025? Is there a known fix or Microsoft acknowledgment for this specific authz token handle leak?Server 2019 Domain Controllers: lsass.exe terminated unexpectedly with status code -1073741819
Basically my issue matches https://learn.microsoft.com/en-us/answers/questions/612097/windwos-2019-lsass-exe-terminated-unexpectedly-wit?source=docs exactly. We have Server 2019 DCs running on VMware vSphere 7.0 U3c. The non-PDC DCs are randomly rebooting with the below event log message: EventID : 1074 MachineName : DC19** Data : {} Index : 544467 Category : (0) EntryType : Information Message : The process wininit.exe has initiated the restart of computer DC19RP on behalf of user for the following reason: No title for this reason could be found Reason Code: 0x50006 Shutdown Type: restart Comment: The system process 'C:\Windows\system32\lsass.exe' terminated unexpectedly with status code -1073741819. The system will now shut down and restart. Source : User32 ReplacementStrings : {wininit.exe, DC19**, No title for this reason could be found, 0x50006...} InstanceId : 2147484722 TimeGenerated : 4/23/2023 5:07:58 AM TimeWritten : 4/23/2023 5:07:58 AM UserName : NT AUTHORITY\SYSTEM The servers are all patched to the current CU - 2023-04 (KB5025229), so they should all have the most recent KB I've found that addresses lsass.exe crashes (KB5010791) installed. I've also noticed that shortly before the lsass.exe crash, there will be an event log similar to the one below, although each references a different WMI filter: EventID : 1065 MachineName : DC19** Data : {} Index : 544466 Category : (0) CategoryNumber : 0 EntryType : Error Message : The processing of Group Policy failed. Windows could not evaluate the Windows Management Instrumentation (WMI) filter for the Group Policy object cn={***},cn=policies,cn=system,DC=fabrikam,DC=com. This could be caused by RSOP being disabled or Windows Management Instrumentation (WMI) service being disabled, stopped, or other WMI errors. Make sure the WMI service is started and the startup type is set to automatic. New Group Policy objects or settings will not process until this event has been resolved. Source : Microsoft-Windows-GroupPolicy ReplacementStrings : {4, 714, 0, 136750...} InstanceId : 1065 TimeGenerated : 4/23/2023 5:07:58 AM TimeWritten : 4/23/2023 5:07:58 AM UserName : NT AUTHORITY\SYSTEM Once the server is back up and running after the reboot crash, WMI appears to be working fine, and I'm not seeing any other errors specifically referencing WMI itself in the period leading up to the crash.
