Forum Discussion
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.
1 Reply
Your isolated test is very useful: the same server works as a member server and breaks the moment it becomes a domain controller, and it works again after demotion. That means the cause is something that applies only to domain controllers, not the Settings app itself. Both the app crash and the Access denied (0x80070005) from the standalone installer fit a permissions or security policy problem. What I would check, in this order:
- Which account you use. On domain controllers the built-in Administrator is the usual case. Store apps such as Settings often will not start for the built-in Administrator unless Admin Approval Mode is on. Test with a different domain admin account, and check the policy User Account Control: Admin Approval Mode for the Built-in Administrator account (it should be Enabled) and Run all administrators in Admin Approval Mode (Enabled).
- The policies that only apply to domain controllers. The Domain Controllers OU gets the Default Domain Controllers Policy and often a hardening baseline. Run gpresult /h c:\gp.html on the DC and look at the User Rights Assignment and file system or registry permission settings applied. Removing groups such as Authenticated Users, ALL APPLICATION PACKAGES or ALL SERVICES from the right places can break Settings and the installer. Compare secedit /export /cfg c:\sec.inf on the DC with the same export on your fresh member server, and the differences will show you which setting it is.
- The logs. Check Event Viewer > Windows Logs > Application for a SystemSettings.exe crash (note the faulting module and exception), and Applications and Services Logs > Microsoft > Windows > AppModel-Runtime for the activation error. For the installer, look at C:\Windows\Logs\CBS\CBS.log and run the update package from an elevated prompt.
- Updating while you fix it. You do not need the Settings app to patch a server: sconfig option 6 downloads and installs updates, PowerShell (the PSWindowsUpdate module) works, or use your WSUS or update management tool, and dism /online /add-package works for a downloaded cumulative update from an elevated prompt.
I would avoid demoting the DCs as a workaround. The comparison of the policy exports will usually point to the setting, and the GPO can then be fixed for good.
