Settings Crashes After DC Promotion; Windows Update Unavailable (Server 2016/2022)

Objective

Resolve the issue where the Windows Settings app crashes immediately upon opening, so that I can access Settings and install Windows updates normally.

Environment and Problem Description

We have two domain controllers in our Active Directory domain, named AD and DC. Both are running Windows Server 2016.

- AD holds all five FSMO roles and runs as a Hyper-V virtual machine hosted on another server.

- DC is a physical server.

Both domain controllers have the same problem. Control Panel opens normally, but the Settings app does not. When I click Settings, a window briefly flashes on the screen without displaying any content (or only the gear icon appears), and then the window immediately closes.

I cannot open Settings-related pages, including Windows Update. As a result, I cannot use the normal Windows Update interface to install updates.

The issue also affects monthly updates downloaded manually from the Microsoft Update Catalog. When I run an update package, the following error appears:

Windows Update Standalone Installer: Installer encountered an error: 0x80070005 Access is denied.

I performed the following test in an isolated environment:

1. Restored a backup of AD and installed a fresh Windows Server 2022 machine named AD3. AD3 was not connected to any other hosts or networks during the test.

2. Before AD3 was promoted to a domain controller, the Settings app worked normally.

3. Immediately after promoting AD3 to a domain controller, Settings stopped opening and began closing immediately.

4. I then transferred all five FSMO roles to AD3 and demoted AD, so that AD was no longer a domain controller.

5. Surprisingly, the Settings app on AD started working again after AD was demoted.

This behavior strongly suggests that the problem is related to the domain controller role or something that changes when a server is promoted to a domain controller. However, I have not identified the underlying cause.

Is there a recommended diagnostic procedure or a known issue that could explain this behavior?

I would appreciate any technical guidance on how to identify the root cause and resolve the problem without having to demote the domain controllers.

Thank you.