Forum Discussion
Can't open Settings app in Win11 24H2 without disabling UAC
I tried upgrading one of our test computers here from Win11 23H2 to 24H2 yesterday. Install ran normally, but when I tried to open the settings app afterwards, it just sits there with the gear icon in the middle of the window and eventually disappears. Found the error in the screen shot in the event log. Tried the same upgrade on another test computer with the same result. Ran all the usual DI_SM (why is that command not permitted in here!!!) and SFC checks which found no problems or if they did, the fixes had no effect on the problem. Also ran a few Powershell commands to reset/reinstall the windows.immersivecontrolpanel package, still no changes.
At this point I wanted to narrow down exactly what was causing the problem, so I wiped one of the test computers and reinstalled 24H2 from scratch on it. After doing so, the settings app worked fine. Ran through my usual new computer setup process, testing the settings app after each step. It stopped working as soon as I joined the computer to our local domain. With this new piece of information, I did some more Googling and found someone that had run into the exact same problem back in 2023. The "fix" they found was to disable UAC by using RegEdit to set HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\EnableLUA to 0. I tried that and the settings app now works. Obviously, that's not a real solution for the problem.
I've also tried removing all GPOs that I can (meaning all except domain-wide ones) and that didn't help. I'm in the midst of looking at the domain-wide policies now, but I don't even know if I should be looking at an existing policy, or a policy that isn't being set. Kinda like looking for a needle in a haystack. Also tried it with a local computer admin account and that had the same problem.
Has anyone else seen this and if so, have you found a resolution that doesn't involve completely disabling an important security feature?
Just in case anyone comes looking about the same, it was a group policy object. The Default Domain object as a matter of fact. Having existed for around 30 years, it had some old, outdated objects that were no longer in GP and a few that still existed but aren't applicable to Win10/Server2016 and later. I created a new policy, added the objects that were still relevant and replaced the problem one with the new one. Settings opens now.
3 Replies
Sorry, I really can't. The default domain policy had existed since the domain was first set up maybe 25, 30 years ago. There aren't many policies that I set in there and a bunch of what was is so old that they weren't even relevant anymore, so I opted to create a new policy and only migrate what was still relevant into that, then replaced the old one. Probably dropped at least 15 policies that all had to do with prior versions of Windows that aren't even relevant with current versions. For all I know, it could've been a policy that wasn't even showing up in GPMC or even some kind of corruption that wasn't manifesting in any other way. All the questions about it is why I chose to go the route I did instead of eliminating entries one by one. Seemed like the better option to guarantee a positive result.
Just in case anyone comes looking about the same, it was a group policy object. The Default Domain object as a matter of fact. Having existed for around 30 years, it had some old, outdated objects that were no longer in GP and a few that still existed but aren't applicable to Win10/Server2016 and later. I created a new policy, added the objects that were still relevant and replaced the problem one with the new one. Settings opens now.
