Many built-in Windows apps broken since late April / early May 2016

That's great work, Castle, and it confirms that changes made in the context of one user account affect other user accounts as well - which should never be the case. All the more reason to always have all required dependency files available locally, rather than having to trigger their download the way you do it.

Has anybody figured out what needs to be done in the context of a new user account to trigger the download of missing language-dependent files? Unfortunately I can't try Castle's approach because the Store app is currently broken for all accounts on my system. Hmph. Have to hope for an update that fixes it for at least one account before I can try this workaround.

Let's be clear - this is just a workaround, and in no way a fix. We can't ask inexperienced Windows users who are just consumers to perform this procedure on a regular basis to fix broken Windows apps.

Thank you castle, your instructions helped me solve my issue.  Here's what occurred to me and what I did on my Surface Pro 3 for posterity.  It helps explain why the reporting on this issue is not quite as widespread, as you'd need to have more than one account in the first place to run into it.

1.  Main user account had zh-hans input enabled.

2.  Created new account test1 to test display rotation.

3.  Logged into new account, notice it's downloading candy crush (I didn't want it installed, perhaps inadvertently clicked the spammy Windows 10 start menu item?)

4.  Uninstalled candy crush.

5.  Logged back into main account.  Windows 10 apps including store are now broken.

6.  Tested new account test1, can still open windows store app.

7.  Created yet another account test2 to test fix.

8.  Logged into test2, and added zh-hans input method

9.  Started windows store app in test2 account, and went to Downloads and updates->Check for updates.  Noticed many of the apps had an update.  Updated just the windows store app.

10. Logged back into main account, now windows store app can open.

11. Checked updates with main account, lists many more updates (apps only on main account, not on new test2 account)

12. At this point the start menu lists the apps as @{Microsoft.WindowsCalculator_..., @{Microsoft.BingNews_4.9.76..., @{Microsoft.Z... etc.  None of them will open including OneNote

13. After updating each app, the name is fixed and can open again.

So what caused this in my case is the main account having input methods in addition to the default, and then creating and login into a new account.  This is definitely broken behavior and it took me 4 hours so far troubleshooting and searching for a solution before I came upon castle's approach.  Microsoft definitely needs to prevent future occurrences of this problem lest it wastes 4 hours for every new person who runs into this.

I do not know if step 8, adding zh-hans to the test2 account, was actually necessary, and I suspect that it may not be.  I still do not have the Microsoft.WindowsStore_11602.1.26.0_neutral_split.language-zh-hans_8wekyb3d8bbwe folder it was complaining about missing in C:\Program Files\WindowsApps.  If another person runs into this, perhaps they can try updating the Windows Store app in the new account without adding the locale that Add-AppxPackage complains about.

Olli,

Have you already tried creating a brand new account, and even that new account cannot open Windows Store app?  That's what worked for me.  As I mentioned in my post, I don't know that it's necessary to add the locale the PowerShell command complains about.  I did add the locale for the new account before updating the store app, but it definitely was not necessary to add the locale just to start the store app.

Hi John

Thanks for your great work. I haven't tried your approach yet but will do so either tonight or tomorrow, and also try your suggestion to not add the language pack to the new account before triggering the Store app update.

Sorry for the delay - pretty busy today with some work and don't want to risk anything until I'm done with that and had a chance to back up my work. Will get back to you here with my findings.

Two thumbs up for you and Castle for figuring this out. It proves yet again that app registration in the context of a user account only takes that user's configuration into account and thus may break apps for other users, as the registration metadata is actually global and machine-wide across all accounts. A critical flaw in the process, but hopefully easy enough to fix, as suggested earlier.

Cheers

Olli

It might be a wise choice that you postponed the trial.

Yesterday's Windows updates look like inlcuding some fixes.

Creating a new account no longer deletes the scaling packages the other account depending on.

So... Microsoft doesn't have a solution to this issue as of today? I'm a Spanish-speaking user so my PC is set up in Spanish. I've been having the problems with the apps and Store for about 2-3 weeks and I really don't have time in my hands to try a manual fix (that and the fact that it will take me longer because I'm no expert in the subject).

Anyone has a solution that doesn't involve any complicated (or time-consuming) process? :/

Do you mean that the issue is still persist even after the yesterday's windows updates applied? It so, yesterday's fix solved the package-deletion problem, but could not recover the already broken accounts. In that case, the workaround of my June 14 post may be still effective.

If you want to try it and feel difficulty in the step 1 and 2, you may start from the step 3. If the step 1 and 2 are skipped, you cannot identify the missing packages. However, you will be able to download all scaling packages by repeating the step 4 and 5 with all of 100%(*), 125%, 150%, 175% scales.

Regarding the language package, John mentioned that the addition of the language input method might not be necessory. If you do not want to be the first runner to reconfirm that, it may be better to do the same language setting for the newly created account as the troubled account before the step 4.

* 100% is added, when I read Jason's post on June 15.

Unfortunately Castle's suggestions did not fix my issue. Here's what I experienced:

Step 1

Ran the AppX dependencies PowerShell script and it returned these dependencies for the Windows Store:

Microsoft.VCLibs.140.00_14.0.23816.0_x64__8wekyb3d8bbwe

Microsoft.NET.Native.Framework.1.1_1.0.23115.0_x64__8wekyb3d8bbwe

Microsoft.NET.Native.Runtime.1.1_1.1.23406.0_x64__8wekyb3d8bbwe

Microsoft.WindowsStore_11602.1.26.0_neutral_split.scale-150_8wekyb3d8bbwe

Microsoft.WindowsStore_11602.1.26.0_neutral_split.scale-100_8wekyb3d8bbwe

Microsoft.WindowsStore_11602.1.26.0_neutral_split.scale-125_8wekyb3d8bbwe

Step 2

Ran the ls *WindowsStore* command in my WindowsApps directory and it returned these results. So it appears I'm missing all of the scaling files.

Microsoft.WindowsStore_11602.1.26.0_x64__8wekyb3d8bbwe

Microsoft.WindowsStore_11602.1.264.0_neutral_~_8wekyb3d8bbwe

Step 3

Created a new user account and changed the scaling to 175% (The default Surface Book resolution is 200%. I run my normal profile at 175%, and at 100% when I'm docked and connected to external displays).

Launched the Windows Store in my new profile and ran all the updates. Note that the Store and many other apps updated, but the Photos app and a few others returned errors and did not update.

Step 4

Signed out of the new account and back into my normal day to day account. Re-ran the ls *WindowsStore* command in the WindowsApps directory and it returned these results. So it only added 1 of the missing scaling files, and of course, not the ones that I needed.

Microsoft.WindowsStore_11602.1.26.0_x64__8wekyb3d8bbwe

Microsoft.WindowsStore_11602.1.264.0_neutral_~_8wekyb3d8bbwe

Microsoft.WindowsStore_11602.1.26.0_neutral_split.scale-150_8wekyb3d8bbwe

Step 5

Attempted to launch the Windows Store, and it didn't open. Since it appears the 150 scaling file had been added, I changed my scaling to 150% and attempted to launch the Windows Store. No joy.

So unfortunately I'm still stuck.

I'm sorry to hear that.

Since your photo's dependencies include 100, 125, and 150 scaling packages, what will happen if you repeat app updates in the step 3 by changing scale to 100% and 125%?

Even if the current scaling is 150%, the app may crush if the one of depending packages is not in the WindowsApp folder, that I experienced in use of 100% scaling when I was missing 150% file.

It looks like the resource package deletion bug was introduced with May 2016 security update (https://support.microsoft.com/en-us/kb/3156421). I have blacklisted that update and so far the issue did not occur in the last two weeks (but uninstalling the update will not solve the issue if it already has occurred).

Here is a short description of the problem:

When AppX Package Manager installs or updates a package for a user, it calculates the set of

dependent resource files based on chosen UI languages and active DPI scaling.

Then, it downloads the resource package data (manifest and the resource files) from Microsoft servers.

When installing the packages, if the installer sees that there is an "unused" resource package, it will be deleted (as of May 2016 update).

The package update is also triggered on user logon (so, if you change DPI or language and log in, the package update is triggered).

Probably, this change was introduced "to conserve disk space" for resource files that were previously

downloaded, but are no longer needed.

When deleting the packages, they are first moved to "c:\Program Files\WindowsApps\MovedPackages" and then immediately deleted after that.

However, the dependency information for all other user accounts is not updated when deleting the "unused" files - so the resource files are still listed as "used" in c:\ProgramData\Microsoft\Windows\AppRepository\StateRepository*.* files.

Also, the precalculated resource dependencies in both the Registry and in *MergedResource-*.pri files that are generated for each user, e.g. S-1-5-21-1251120248-1320308648-2577036869-1104-MergedResources-14.pri for user with SID 1-5-21-1251120248-1320308648-2577036869-1104 are not updated.

When apps are loaded, the ***MergedResource-*.pri files are loaded first, and since they reference nonexistent resource files (and resource manifests), the app loading fails.

Sometimes, the issue can be resolved by creating a user account, setting the relevant DPI or UI Language, logging out, logging in, and instaling the relevant package from Store.

If the app version from Store matches the registered app version for the impacted user, it will fix the problem for the impacted user.

But, if the app was already updated since that time, the Store version will not match the broken version for the impacted user, so the impacted user will still not be able to run, update or even uninstall the app.

There should be, at the very least, a -Force switch for AppX PowerShell cmdlets that allow package reinstall/redownload/reset regardless of any missing dependencies or inconsistencies.

Or, a special Reset-AppxPackage cmdlet that resets the package to the "factory defaults" and downloads any missing data, like you can always do in Android by clicking "Clear Data/Clear Cache" if you have any problem with an app.

It looks like the June 2016 security update has the package deletion behavior reverted (probably after many complaints), but it still does not automatically redownload previously deleted package data (although that is definitely possible - that data originally comes from Microsoft servers!).

So, the fix is not really complete.