Home > Computers and Internet > SettingSyncHost is consuming CPU

SettingSyncHost is consuming CPU

I had an issue where the Host Process for Setting Synchronization (SettingSyncHost.exe) process was constantly consuming CPU whenever the computer was connected to a network that wasn’t a metered connection. It would run at around 31% CPU nonstop. The reason why it was running so hard was that it was constantly checking the files in %localappdata%\Microsoft\InputPersonalization\TrainedDataStore\en-us; but that directory had a problem. Instead of having only one or two files like it is designed to have, it had over 100,000 files.

The reason why TrainedDataStore had so many files in it, is that the user account I use didn’t have permissions to the HKEY_CURRENT_USER\Software\Microsoft\InputPersonalization\TrainedDataStore\en-US\2 registry key. Which is very strange, the logged in user should always have permissions to everything under HKEY_CURRENT_USER. So what was happening was that the InputPersonalization process was writing a file to TrainedDataStore\en-us, and then checking the registry key, but would get an error, and bail out. Then it would do that over and over again. The Host Process for Setting Synchronization would see that a change happened in that directory (a new file had been created) and then scan the directory over again. This would consume 31% CPU all day. Thankfully it wasn’t constantly uploading the changes to SkyDrive, that would have been really bad.

The crazy thing is that the local user was the owner over the en-US registry, but the local administrators group was the owner of the en-US\2 directory. Given that that key is under HKEY_CURRENT_USER that is really, really weird. I have no idea how it happened, but apparently the first time that InputPersonalization ran as that user, it must have been kicked off with elevated permissions when creating the registry key.

To fix the issue I logged in as the administrator, found the users key under HKEY_USERS, right clicked on the Software\Microsoft\InputPersonalization\TrainedDataStore\en-US\2 key and selected Permissions. I then pressed Advanced and at the top of the dialog window was able to change the owner. Once the owner was changed to the correct user, the %localappdata%\Microsoft\InputPersonalization\TrainedDataStore\en-us directory emptied quickly and the Host Process for Setting Synchronization hasn’t been a bother since.

Below are two screen shots from regedit. They show that en-US has the correct owner, but en-US\2 does not, it has Administrators as the owner.

TrainedDataStore\en-US Owner: Jared

TrainedDataStore\en-US Advanced Security Settings

TrainedDataStore\en-US\2 Owner: Administrators

TrainedDataStore\en-US\2 Advanced Security Settings

  1. Donny Johnson
    December 22, 2013 at 8:47 pm

    I’ve been tracking this problem for a few weeks now trying to narrow down the specific permission, you have nailed it! These seems like a bug that MS should be on top of, I’ve had two seperate machines with two different MS accounts have this problem!

  2. rbiernath
    September 25, 2017 at 8:34 am

    This works for windows 10 as well. Also, you need to do this for whichever languages are installed on the computer. I had the spanish keyboard enabled so I had to do this for the es-ES keys as well

  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: