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.Cannot Sign into Edge on Domain Controllers running Windows Server 2019 Standard
I know this is more of an Edge issue than a Server issue, but it's specific to Server 2019 Standard running as a domain controller, so I'm starting here. Edge version: 108.0.1462.76 (Official build) (64-bit) OS: Windows Server 2019 Standard (Build 17763.3770) When I launch Edge on any of my 23 Domain Controllers running Windows Server 2019, I am unable to sign into Edge with my "work or school" account (my AD/AAD credentials). I have no issues signing into Edge on Server 2019 member servers. When I first launch Edge on a member server, it automatically logs me in and gives me the below screen: However, when I launch Edge on a domain controller I get this: After clicking "Sign in to sync data", I get an MS login window: Then, upon typing in my AD/AAD credentials, I get a popup window with the below message: We can't sign you in right now The Microsoft Edge team has been notified of this issue. Please try again later. Error code: 3, 15, -2146893039 edge://signin-error/ Any suggestions?
RPC server is unavailable
After latest update in Monday (11.1.2022), our Windows server 2019 domain controller was crashing every 4 minutes or so After trying to log in via RD or Hyper-V, server replied "RPC server is unavailable" and crashed. I fixed the issue with removing virtual network switch for DC (I guess removing network cable will work similarly), logging in and uninstalling update KB5009557. Hope this helps somebody.Multiple domain controllers and domain time server
I maintain existing solutions, almost never setting up an entire new network. One of my customers has three DC's (DC1, DC2, DC3). When running nltest /dsgetdc:<DomName> /timeserv on the servers I'm getting different results. Some times pointing to DC1, some times DC3. W32tm /query /source also gives varying results, some looking to free running clock, some to a DC, some to CMOS. I've read this https://docs.microsoft.com/en-us/services-hub/health/remediation-steps-ad/configure-the-root-pdc-with-an-authoritative-time-source-and-avoid-widespread-time-skew about network time servers. The customer's Default Domain Controller Policy (group policy) has the following settings enabled - Configure Windows NTP Client - Enable Windows NTP Client - Enable Windows NTP Server With the settings in place, on the Default Domain Controller Policy (which is applied to each of the DC), wouldn't it make each DC fight over who is the time server for the domain? Thank you in advance.
Windows Server 2012 - Replication Event on Secondary Domain Controller
We are looking for a way to track when a user account was created/delete/changed on the secondary domain controller. When we make the change on the primary, I can see the event in the event log but we want to see that replication event on the secondary domain controller. I'm not sure what I'm looking for and we have so many logon/logoff events that the event log only holds 2-3 minutes of data before filling up. Since it takes time to replicate, I can't catch the event. I've gone into the group policy settings for the domain controllers and turned on advanced audit for the replication service but it's really only showing me that it was able to talk to the other domain controller, not what was actually replicated. I'm hoping there is a way that we can track the change, even if it is as simple as something like a change was made. It doesn't have to be in great detail. If maybe someone knows what event id is that I need to look for then I can filter through and find it. Maybe I'm looking in the wrong place all together? Any help would be greatly appreciated.
