Archive

Archive for December, 2013

Unable to start some apps after upgrade to Windows 8.1

December 29, 2013 Leave a comment

After upgrading my parents Windows 8 computer to Windows 8.1 all of the user accounts on the computer didn’t have the Bing Weather app nor the Skype app. It was strange, the live tile for the apps were where they were on the Start Screen before the u;grade, but instead of showing anything they were rectangles with a small x in the lower right hand corner; and launching the resulted in showing just the background color. When I tried to reinstall the apps from the Windows Store the installation process would die with error 0x8004005, which is error code 5 which is Access Denied. That is really strange, because the whole point of WinRT apps is that a standard user should be able to install them to their own profile with no permissions issues at all.

My parents have a great setup on their computer, they have an administrator account that they never log into, and all of the users on the computer are standard users and sign in with their own Microsoft accounts.

I ran Process Monitor and filtered by Result is Access Denied. This showed a couple of entries but the one which looked interesting was one that was trying to access HKEY_USERS\\Software\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Notifications\BackgroundCapability\S-1-15-2-2040986369-264322980-3882385089-1970153872-3662121739-3363227934-2464603330\App.AppX0reyrkpf8fvpmyz1tg3wc7fwjvf2e5c5.wwa. I opened regedit.exe as elevated, and could see the S-1-15-2-2040986369-264322980-3882385089-1970153872-3662121739-3363227934-2464603330 regkey, but I couldn’t expand it. That seems to be by design for every key under BackgroundCapability, so I gave it little heed. I then reopened regedit as the standard user and navigated to S-1-15-2-2040986369-264322980-3882385089-1970153872-3662121739-3363227934-2464603330 under HKEY_CURRENT_USER. I could expand it, but I could not open the App.AppX0reyrkpf8fvpmyz1tg3wc7fwjvf2e5c5.wwa child. This was strange because I could open its siblings. I suspect that the issue was similar to a previous issue that I had with the TrainedDataStore where the owner of a registry key under HKCU isn’t the current user.

I then reopened regedit as elevated and deleted the S-1-15-2-2040986369-264322980-3882385089-1970153872-3662121739-3363227934-2464603330 key. Then I went back to the Windows Store and was able to install the app. So the issue is most likely that sometime during upgrade the Owner of some registry keys under the user profile get reassigned to something other than the user (which is bad).

To fix this issue on your own, open regedit and navigate to HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\Notifications\BackgroundCapability. Its children will be Windows Security Principles, in my case the interesting one was S-1-15-2-2040986369-264322980-3882385089-1970153872-3662121739-3363227934-2464603330. Find the one where you can not see the values for it’s children (a pop up dialog will open informing you that you do not have permissions). Then reopen regedit with elevated permissions and find that regkey under HKEY_USERS and delete it. The Windows Store should be able to install the apps after that.

SettingSyncHost is consuming CPU

December 16, 2013 1 comment

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