Why does SystemSettings.exe automatically start 5 minutes after logon?

[NoelC]

If I boot my Win 10 test VM, and leave it completely alone for 5 minutes, SystemSettings.exe and ApplicationFrameHost.exe are automatically started.  SystemSettings.exe goes immediately to Suspended state.

With BigMuscle's ModernFrame-x64-Debug.dll in place it's obvious when it happens because a debug console window opens for ApplicationFrameHost.exe.

Since mine is a system on which I don't normally expect to run an App of any kind, I sure as hell don't want a copy of SystemSettings.exe sitting in the background.

I will be sweeping through the Task Scheduler looking for what it is that's starting SystemSettings.exe after 5 minutes of idle time, but if you have any ideas - or if you also see this happen on your Win 10 system - please let me know.  What I don't know is whether most folks have enough Apps that this stuff always starts right up after login normally.

I've already removed a scheduled run of provtool at 5 minutes after bootup, but that didn't stop the run of SystemSettings.exe.

-Noel

Edited September 15, 2016 by NoelC

[zolotron]

Have you tried to go to settings/Privacy/Background apps and turn the Settings app off

[NoelC]

Hm, there are no Apps on this system except Settings, and sure enough it appears in the "Let apps run in the background" list.  I've never noticed it there before, nor would I have expected that it would need to run in the background.  Now it's Off:

Testing now...  I have to leave the system completely alone for at least 5 minutes...

Edit:  Nope.  SystemSettings.exe started exactly 5 minutes after I booted the machine anyway.  I am not surprised.

Thanks for trying to help, zolotron.

-Noel

Edited September 22, 2016 by NoelC

[zolotron]

You're welcome and seems MS do their best to make Win 10 a bigger mess with every new update and upgrade

[xpclient]

I have noticed that apps (app processes) start in the background on Windows 10 even though you have disallowed them to run in the background.

[dencorso]

@NoelC: Launch Process Hacker via the Startup folder (or an equivalent means) and save a process list just after boot.
Wait for the debug console window to open for ApplicationFrameHost.exe and, before dismissing it, save another process list.
Compare both lists. What's different? Maybe we can learn something from this exercise, besides what you've already found out...

[NoelC]

I'd love to learn something from this exercise - like how to stop this system behavior of running an App I don't want running in the first place.

ApplicationFrameHost.exe and SystemSettings.exe are the newly started processes left running after the 5 minute mark.  And the system has to be completely idle for them to run; if I even move the mouse it delays the start, so actively saving a process list will prevent it from happening.  The best I could do with that limitation is to save a list from 5 minutes before and directly after.  I can, however, easily get screen grabs of the process list that bracket the occurrence by setting up a timed, regular screen grab with IrfanView.  Here are before and after screen grabs:

Is there something more specific you would you want to look for?  Maybe I can find a way to capture it.

From what I know, ApplicationFrameHost is a wrapper that facilitates Apps to run on the desktop.  SystemSettings.exe is of course the Settings App itself, which is the only App I have on this system.

I don't know what starts it.  If it's a scheduled job, I haven't found it yet, and bear in mind I've already disabled a LOT of needless scheduled jobs.

Since the Settings App starts up virtually instantly whether it's running yet or not, it seems to me it's no more than a waste of resources to start it ahead of time - presumably because a suspended App takes less time to come up than one that's not running at all - and I don't care how "suspended" it is, there are two processes in the process list that don't need to be there.  SOMETHING is surely being used, and if nothing else the process list is just that much more difficult to scan visually.  Chances are would go for days or weeks without running the Settings App.  Pretty much the only times would be when every few weeks I would choose to install updates.

I had build 10586 down to where it would settle to 42 processes to support an idle desktop and deliver all the functionality I expect.  There are 4 or 5 more processes now with build 14393, yet as far as I can see it's no more responsive, and delivers no more functionality.

Edit:  If I terminate ApplicationFrameHost/SystemSettings/conhost, they will come back again after 5 more minutes of inactivity.

-Noel

Edited September 23, 2016 by NoelC

[qwerty12]

Try StartIsBack++ with its options to "not prelaunch SearchUI and ShellExperienceHost processes" and "not prelaunch frequently used modern apps", which do what they say on the tin -- for many months, there's been no SystemSettings.exe running on my laptop until I start Settings myself.

I guess all this is done because instead of Microsoft actually, y'know, putting in work making UWP apps start up faster, they decided prelaunching everything would be OK and nobody would complain about the new calculator showing a splash screen while it loads any more ...

Edited September 23, 2016 by qwerty12

[dencorso]

And... before you do that, since you run it with the UAC turned off, I'd guess you may rename a system file without triggering its instant replacement, right?
If so, just rename it to SystemSittings.exe, and let's see whether an error gets thrown, and if so, which process throws it. Is that feasible?

[NoelC]

It's good to know a tweaking application has discovered the secret - that says there IS a way to do it.  Thanks for the info, qwerty12.

System Protection still functions, so I'm not sure a rename of SystemSettings.exe will stick.  It's worth a try, though, just to see if anything gets logged.

Edit: 

Got "Access is denied" errors trying to rename C:\Windows\ImmersiveControlPanel\SystemSettings.exe even in a CMD window running as SYSTEM. 

Then when taking ownership and changing permissions, a pop-up "You are about to change the permission settings on system folders.  This can reduce the security of your computer and cause users to have problems accessing files.  Do you want to continue?"

It fought me a while longer, but I prevailed.  SystemSittings.exe it now is.  The 5 minute wait has begun.

Edit 2:

LOL, ApplicationFrameHost.exe started after 5 minutes, but of course not SystemSettings.exe, which did not exist.  I guess this warrants a similar trial with ApplicationFrameHost.exe.

This was logged in the System Event Log when SystemSettings.exe was not able to be started:

Unable to start a DCOM Server: microsoft.windows.immersivecontrolpanel as Unavailable/Unavailable. The error:
"2"
Happened while starting this command:
"C:\WINDOWS\ImmersiveControlPanel\SystemSettings.exe" -ServerName:microsoft.windows.immersivecontrolpanel

Edit 3:

Renaming ApplicationFrameHost.exe to ApplicationFrameHosed.exe sure enough stopped the autostart of SystemSettings.exe, but didn't log any informative error messages.  It's also not a reasonable workaround because that basically prevents Settings from being run at all.

I also experimented with blocking the "TelemetryHelper" - %SystemRoot%\ImmersiveControlPanel\Telemetry.Desktop.dll - several different ways on the theory that maybe something's trying to start telemetry operations 5 minutes after bootup, and that didn't net any useful results.  Basically it caused the Settings App to hang on startup.

So given what's been learned here, the question begins to crystallize...  From what list do DCOM servers get started?

I'll be fooling around with this registry key next...

HKEY_CLASSES_ROOT\Extensions\ContractId\Windows.BackgroundTasks

Edit 4:

Fooling with that key didn't help the problem.

But it DID reveal that there's yet another monkey wrench being thrown in the system by Microsoft:  I couldn't actually restore the default content of that key.  And I do know how to set registry permissions, and how to temporarily stop Windows Defender.

-Noel

Edited September 24, 2016 by NoelC

[aviv00]

try to remove settingssync package

[dencorso]

But now we know SystemSettings.exe is being started by the ApplicationFrameHost.exe, right?
So, whatever is happening under the covers, must be acting on the ApplicationFrameHost.exe...

[NoelC]

51 minutes ago, aviv00 said:

try to remove settingssync package

That's been long gone for a while now, and I haven't noticed any attempts to communicate associated with.  But thanks very much for the idea.  I think it's as deconfigured as it can be, but if you can think of places I could look for remnants of Settings Sync, I'll certainly double-check.

-Noel

[NoelC]

9 minutes ago, dencorso said:

But now we know SystemSettings.exe is being started by the ApplicationFrameHost.exe, right?
So, whatever is happening under the covers, must be acting on the ApplicationFrameHost.exe...

Not quite, I think ApplicationFrameHost is just responsible for making a space on the desktop for the Metro application to show itself over, and automatically starts when any App is run.

What I think is happening is that there's a list - though I'll be darned if I know where - of DCOM servers to be automatically started by the system.  I'm imagining that manipulating said list to not contain SystemSettings.exe will fix the entire problem.

"We'll need a search running..."

-Noel

Edited September 24, 2016 by NoelC

[dencorso]

BTW, how are you becoming TrustedInstaller on 10? With Joakim's tools? Up to 8.1 I'm sure it's the most reliable way to do it.