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 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)...
Issues restoring Windows 2025 domain controllers from snapshots
Build 26280.ge_prerelease.240824-1650 I am running the Windows 2025 domain controllers deployed on Hyper-V virtual machines. Hyper-V is installed on Standard D16s v3 Azure virtual machine. Scenario 1 When I create a Azure VM snapshot and then deploy a new Azure VM from that snapshot, the Windows 2025 Hyper-V based domain controllers won't boot (there is a back screen with infinite loading spinner). Scenario 2 - A Hyper-V checkpoint is created for Hyper-V based domain - The domain controller is restored from the checkpoint - The domain controller is backed up using Windows Server backup - The domain controller is restored to a new Hyper-V VM from Windows server backup - After the recovery, it won't boot with same back screen with infinite loading spinner as in Scenario 1 Both scenarios work well in all previous Windows versions.
