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?
Windows Server 2025 Failover Cluster Live Migration Issue
Hi Everyone, I am facing an issue in a Hyper-V Failover Cluster environment where Live Migration intermittently fails due to a service logon-related problem. The environment was previously working normally, but now whenever we attempt to Live Migrate a VM between cluster nodes, the migration fails unless we manually run “gpupdate /force” on the Hyper-V host first. After running gpupdate /force, the migration works temporarily, but the issue returns again during the next migration attempt. This makes it appear that some policy or permission is not being applied consistently on the cluster nodes. During troubleshooting, I attempted to add “NT VIRTUAL MACHINE\Virtual Machines” to the “Log on as a service” policy under Local Security Policy > Local Policies > User Rights Assignment. However, the account does not appear or resolve in the Object Picker when trying to add it manually. At this stage, I am trying to understand whether this is related to a domain GPO overwriting local policy settings, a Failover Cluster permission issue, or something specific to Hyper-V virtual machine accounts. Has anyone encountered a similar issue where Live Migration only works after running gpupdate /force? Also, is there a correct method to add “NT VIRTUAL MACHINE\Virtual Machines” to the “Log on as a service” policy, or should this permission already exist by default on Hyper-V hosts? Any guidance or recommendations would be greatly appreciated.
Windows Admin Center Preview - 2511 English [MSI Corrupt]
When attempting to launch the WindowsAdminCenterPreview_2511.msi, I received an error message (See Below). In addition, when I test the MSI using 7zip, the archive fails to validate. This occurred downloading the installer package twice over a two-day period. My system info is below.Server 2025 Core ADDS DC, Network Profile Showing as "Public" and not as "DomainAuthenticated"
OS: Windows Server 20225 Standard Core (no GUI), build 26085.1 Role: ADDS, DNS ForestMode: Windows2025Forest DomainMode: Windows2025Domain Platform: Hyper-V guest When standing up a clean Windows Server 2025 using server core and configuring it as a domain controller, the network category (profile) always shows as "public." A clean load of Windows Server 2022 with server core as a domain controller has the same behavior. However, in Server 2022, the fix is to add DNS as a required service to the nlasvc (Network Location Awareness) service. Once that is done, the network category reflects "DomainAuthenticed" and persists between reboots. In Server 2025, the nlasvc service does not have the same requiredservices as Windows Server 2022, and it does not start automatically. Even after configuring the nlasvc service the same way it is in Server 2022 and adding DNS as a required service, the network category still reflects "public." The only way to get the network category to properly reflect the "DomainAuthenticated" status is to disable and reenable the network adapter after each reboot.
VBS and TPM Chip
Hi All In the Microsoft documentation a TPM Chip is a hard requirement for VBS: https://learn.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-vbs But VBS can be enabled without a TPM Chip. VMWare also describes this scenario: https://blogs.vmware.com/vsphere/2018/05/introducing-support-virtualization-based-security-credential-guard-vsphere-6-7.html I'm now wondering, if the Microsoft Article is wrong and it is an optional requirement in fact; or if the feature is only supported, if a TPM Chip is present. As Windows Server 2025 comes with VBS enabled by default, this could be an issue (Most visualized Systems to hot have a TPM Chip by default)...
WS2025 Preview (26100.1) fails to boot after joining WS2016 forest
I installed WS2025 Preview (Datacenter, 26100.1) in a virtual machine and after joining the domain, the box is rendered unbootable (boot loops). I can reinstall and do other tasks as a standalone server with no problem but joining the domain immediately bricks the VM, 100% of the time. The forest is running at functional level WS2016. I disabled all GPs and verified with gpresult they are not applied. Safe mode boots if you need me to poke around. Am working to get a kernel debugger attached. No memory dump is generated and disabling reboot on errors yields nothing.If only MS would take more care of details...
Currently setting up the "deduplication-corruption repo with newest pre-release Server 2025 as L1 and L2 VMs". And then I see this: It is still the problem a lot of "Client only, never needed or wanted on a server by default" stuff creeps into the Server UI. Another example of today is this bad default setting: Microsoft could do so much better if it would take more care of details, reduce the Marketing/Public-Relations (previously known as Propaganda Departement) budget and invest more in actual quality. Please Dave Cutler, you have to rescue Windows - AGAIN, like you did when XP was released (i.e. when it was SP0, I remember how bad it was at first)...
