Has anyone encountered Windows Server 2019 domain controllers failing to boot after installing the August or September 2026 cumulative updates? In our Hyper-V environment, every writable DC and RODC fails after installing KB5120238, KB5121645, KB5122876, or KB5126144 through MECM. The update reaches about 30% during reboot, then the system crashes with CRITICAL_SERVICE_FAILED (bugcheck 0x5A). The fourth parameter is 0xC0000428, indicating that Windows could not verify a file's digital signature, and the crash occurs during driver initialization in nt!IopLoadDriver and related routines.
All Windows Server 2019 member servers install the same updates successfully. The affected systems run AD DS, DNS, DHCP, and file services, with Sophos installed, but removing Sophos did not change the behavior. Secure Boot, Hyper-V settings, BCDEdit configuration, CBS logs, Code Integrity logs, and memory dumps have not revealed an obvious offending driver or package.
The only reliable recovery so far is booting into recovery tools and running dism /image:C: /cleanup-image /revertpendingactions, which rolls back the update. Has anyone identified the driver or component involved, found a connection to AD DS or Secure Boot certificate changes, or discovered a workaround that avoids reverting the update?
5 Answers
One useful comparison would be whether the affected machines all received the new Secure Boot servicing or certificate payload at the same time. Also verify that the recovery environment is using the correct system volume when running DISM; otherwise it is easy to roll back the wrong image. I have not seen a confirmed universal workaround beyond removing the pending update actions.
The 0xC0000428 status makes the Secure Boot certificate and boot-time signature changes worth investigating. The update may be exposing a driver or boot component whose signature is no longer accepted. I would compare Code Integrity events and the loaded-driver list before and after the update, and test with Secure Boot certificate updates handled separately if possible.
We skipped the August patches but installed the September cumulative and .NET updates on three Server 2019 domain controllers and two DHCP servers without seeing this failure. That could mean the issue depends on the August-to-September servicing sequence, a specific hardware or security product combination, or a component unique to the affected controllers.
Since the same updates work on your member servers and the problem remains after removing Sophos, AD DS itself or another domain-controller-specific boot dependency may be involved. I would keep one recovered DC isolated from further deployment, capture the exact pending package and driver state, and open a Microsoft support case with the memory dump, CBS logs, and Code Integrity events. Until the cause is confirmed, retaining a known-good DC and using revertpendingactions is the safest recovery path.
A few people have reported unusual behavior on domain controllers after the August updates, including services failing to start or systems needing multiple hard resets before booting normally. That does not prove the same root cause, but it suggests testing the update chain on a non-production DC before deploying it broadly.
The dump pointing at nt!IopLoadDriver only shows where Windows failed while initializing a driver; it does not necessarily identify the unsigned file. The Code Integrity event immediately before the crash may contain the actual image name.