Forum Discussion
Server 2019 Domain Controllers BSOD After August/September 2026 CUs (KB5120238 / KB5122876)
Wondering if anyone else is seeing this.
We've encountered a consistent issue across our environment where all Windows Server 2019 Domain Controllers fail to boot after installing the August and September 2026 cumulative updates. The behaviour is 100% reproducible and affects both writable DCs and RODCs.
Updates are being deployed from MECM.
Affected Updates
- KB5120238 - August 2026 Cumulative Update
- KB5121645 - August 2026 .NET Framework Update
- KB5122876 - September 2026 Cumulative Update
- KB5126144 - September 2026 .NET Framework Update
Environment
- Windows Server 2019 (Build 17763)
- Hyper-V virtual machines
- Roles:
- Active Directory Domain Services
- DNS
- DHCP
- File and Storage Services
- Sophos Server Endpoint installed
- Sophos Core Agent 2026.2.1.3.0
- Sophos Intercept X 2024.1.2.1.0
Affected Servers
- 2 x Windows Server 2019 writable Domain Controllers
- 3 x Windows Server 2019 Read-Only Domain Controllers
Unaffected Servers
- 14 x Windows Server 2019 servers, which are not domain controllers
This is what makes the issue particularly interesting. Every Server 2019 DC is affected, while all member servers install the same updates without issue.
Symptoms
Updates install successfully through MECM.
After rebooting to complete installation, the server applies the update to 30%, then restarts, and when booting crashes during start-up with:
CRITICAL_SERVICE_FAILED
The machine then enters a boot loop and never completes start-up.
Recovery
The only successful recovery method we've found is:
dism /image:C:\ /cleanup-image /revertpendingactions
After rebooting, Windows rolls back the update and the server starts normally.
Investigation Performed
- Analysed MEMORY.DMP using WinDbg
- Checked CBS.log
- Reviewed Code Integrity Operational logs
- Reviewed BCDEdit configuration
- Verified DCDIAG results after rollback
- Compared Secure Boot settings
- Compared Hyper-V configuration
Sadly, nothing obvious stands out.
Bugcheck Information
Event ID 1001 reports: 0x0000005A
Fourth bugcheck parameter: 0xC0000428
WinDbg analysis shows: CRITICAL_SERVICE_FAILED (0x5A)
Crash occurs during driver initialization within:
nt!IopLoadDriver
nt!IopInitializeSystemDrivers
nt!IoInitSystem
The status code "0xC0000428", translates to "Windows cannot verify the digital signature for this file.".
What We've Ruled Out
- Sophos versions are identical on affected and unaffected servers.
- Issue persists even after Sophos is removed.
- Secure Boot is enabled everywhere.
- Hyper-V platform is identical.
- No specific third-party driver has been identified in dump analysis.
- CBS logs don't identify a problematic package or driver.
Current Assessment
At this point the evidence seems to indicate a boot-time driver signature validation issue introduced by the August/September 2026 cumulative update chain that specifically impacts Windows Server 2019 Domain Controllers.
I'm particularly interested to know:
- Has anyone else seen this on Server 2019 DCs?
- Any correlation with AD DS specifically?
- Has anyone identified the driver or component failing signature validation?
- Any successful workaround other than reverting pending actions?
1 Reply
Your five domain controllers failing while fourteen member servers remain unaffected is an important pattern, but it does not establish an AD DS defect. The strongest clue is 0xC0000428, which Microsoft identifies as STATUS_INVALID_IMAGE_HASH, indicating an image could not be verified against its catalog.
Since you already examined the dump and Code Integrity operational log, repeating those checks alone is unlikely to help. During a maintenance window, capture a fresh failure on one recoverable DC with Code Integrity verbose logging enabled, then preserve the dump, CBS logs, and boot configuration before recovery. Provide these privately to Microsoft Support, alongside the exact cumulative updates and your writable DC versus RODC results. Ask them to identify the rejected image and confirm any applicable servicing issue. I cannot confirm a documented fix for those updates; disabling signature enforcement would conceal the failure rather than resolve it.
