Home apps microsoft store troubleshooting windows

Troubleshooting Microsoft Store App Launch Failures on Windows Client

Updated: • 0 • min read
Table of Contents

Microsoft Store Apps on Windows can sometimes fail to launch, hindering user experience and productivity. This article provides guidance on diagnosing and resolving issues where Microsoft Store Apps fail to start due to incorrect default registry or file permissions. These issues can manifest in different ways, as outlined below.

Issue 1

When attempting to launch a Microsoft Store App, the application may appear to start briefly, but then Windows abruptly returns to the Start screen. Notably, no error message is displayed on the screen, leaving users without immediate clues about the problem.

To diagnose this issue, examine the Microsoft-Windows-Immersive-Shell event log. Event ID 5961 is often logged under the path: Applications and Services Logs\Microsoft\Windows\Apps\Microsoft-Windows-TWinUI/Operational.

The event log will contain details similar to the following:

Log Name:      Microsoft-Windows-TWinUI/Operational
Source:        Microsoft-Windows-Immersive-Shell
Date:          DateTime
Event ID:      5961
Task Category: (5961)
Level:         Error
Keywords:
User:          UserName
Computer:      ComputerName
Description:
Activation of the app <app name> for the Windows.Launch contract failed with error: The app didn't start.

Troubleshooting Microsoft Store App Launch Failures

In this event log, <app name> refers to the specific Microsoft Store App that failed to launch. Examples of <app name> values include:

microsoft.windowscommunicationsapps_8wekyb3d8bbwe!Microsoft.WindowsLive.Chat

Many built-in Microsoft Store Apps share similar prefixes. Here are some common prefixes you might encounter:

Microsoft.BingFinance_8wekyb3d8bbwe!
Microsoft.BingMaps_8wekyb3d8bbwe!
Microsoft.BingNews_8wekyb3d8bbwe!
Microsoft.BingSports_8wekyb3d8bbwe!
Microsoft.BingTravel_8wekyb3d8bbwe!
Microsoft.BingWeather_8wekyb3d8bbwe!
Microsoft.Bing_8wekyb3d8bbwe!
Microsoft.Camera_8wekyb3d8bbwe!
Microsoft.Media.PlayReadyClient_8wekyb3d8bbwe!
microsoft.microsoftskydrive_8wekyb3d8bbwe!
Microsoft.Reader_8wekyb3d8bbwe!
Microsoft.VCLibs.110.00_8wekyb3d8bbwe!
microsoft.windows.authhost.a_8wekyb3d8bbwe!
microsoft.windowscommunicationsapps_8wekyb3d8bbwe!
microsoft.windowsphotos_8wekyb3d8bbwe!
Microsoft.WinJS.1.0.RC_8wekyb3d8bbwe!
Microsoft.WinJS.1.0_8wekyb3d8bbwe!
Microsoft.XboxLIVEGames_8wekyb3d8bbwe!
Microsoft.ZuneMusic_8wekyb3d8bbwe!
Microsoft.ZuneVideo_8wekyb3d8bbwe!

Issue 2

Another manifestation of Microsoft Store App launch failures is when users are unable to start any Microsoft Store App, and additionally, the Start screen and Windows Search functionality become unresponsive. In this scenario, error events are logged in the Application logs.

The Application log will contain entries similar to the following:

Log Name: Application
Source: Application Error
Event ID: 1000
Task Category: (100)
Level: Error
Keywords: Classic
User: N/A
Description:
Faulting application name: xxxx.exe, version: 10.1605.1606.6002, time stamp: 0x5755acef
Faulting module name: xxxxxx.dll, version: 10.0.14393.1198, time stamp: 0x5902836c
Exception code: 0xc000027b
Fault offset: 0x00000000006d5eab
Faulting process id: 0x29c4
0xc000027b: An application-internal exception has occurred. This error occurs when an access denied error happens during app initialization that is fatal and cause an exception that leads to the crash.

Application Error Event ID 1000

When using Process Monitor to observe the behavior of the failing Apps’ executables or related files, you might observe “access denied” errors being logged. These errors indicate that the currently logged-on user lacks the necessary permissions. The missing permissions often relate to:

  1. Registry hives and their subkeys:

    1. HKEY_CLASSES_ROOT
    2. HKEY_LOCAL_MACHINE\Drivers
    3. HKEY_LOCAL_MACHINE\HARDWARE
    4. HKEY_LOCAL_MACHINE\SAM
    5. HKEY_LOCAL_MACHINE\SOFTWARE
    6. HKEY_LOCAL_MACHINE\SYSTEM
    7. HKEY_USERS

  2. File subsystem locations:

    1. Program Files - Requires Read, Read & Execute, and List folder Contents permissions.
    2. Windows - Requires Read, Read & Execute, and List folder Contents permissions.
    3. Users\\AppData\Local\Microsoft\Windows\WER - Requires Special Permissions: List folder / read data, and Create Folders / Append Data.

Cause for Issue 1

Issue 1 typically arises when the default permissions for the registry or file system have been altered. The All Application Packages group, a well-known security principal with a predefined Security Identifier (SID), is crucial for Microsoft Store Apps to function correctly. This group must possess specific access rights to certain registry and file system locations. If these permissions are modified or removed, apps may fail to launch as described in Issue 1.

File System Permissions

Cause for Issue 2

Issue 2 is specifically caused by missing read permissions for the All Application Packages group on critical registry keys or file system locations. The error code 0xc000027b in the Application log strongly suggests a permissions problem. This error, without exception, points to insufficient permissions for the ALL APPLICATION PACKAGES group in either the registry or the file system. When the system attempts to initialize a Microsoft Store App, it needs to access these resources, and if the necessary read permissions are absent, the app initialization process fails, leading to the observed crashes and errors.

Resolving Microsoft Store App Launch Failures: Restoring Permissions

To rectify these Microsoft Store App launch failures, it’s essential to restore the registry and file system permissions to a state that allows Microsoft Store Apps to function properly. The resolution process depends on how the permissions were altered, whether manually or through Group Policy.

If you are utilizing Group Policy to manage permissions, or if you are unsure whether Group Policy is involved, follow these preliminary steps before attempting to restore permissions:

  1. Isolate Group Policy Influence: To prevent domain-based Group Policy from reapplying incorrect permissions and potentially re-introducing the issue after you have corrected it, temporarily isolate the affected computer from the domain’s Group Policy. You can achieve this by either:

    • Unjoining the computer from the domain entirely.
    • Placing the computer in a test Organizational Unit (OU) within Active Directory that has block policy inheritance enabled. This setting prevents Group Policies linked to parent OUs from being applied to the test OU.

  2. Apply Necessary Permissions: After isolating the computer from potentially interfering Group Policies, proceed to manually add the required permissions as detailed in the following sections.

  3. Address Group Policy (If Applicable): If Group Policy is indeed managing these permissions, you will need to identify and edit the relevant Group Policy Object (GPO) to ensure it no longer causes permission issues for Microsoft Store Apps. This might involve modifying existing file system or registry permission settings within the GPO to include the necessary access for the “All Application Packages” group.

The core resolution revolves around ensuring the “All Application Packages” group has the correct permissions. Follow the methods below to diagnose and fix the permissions.

  1. Determine File System Permission Changes: First, assess whether file system permissions have been modified from their defaults. If not, consult the More Information section for further troubleshooting.

  2. Identify Change Method (File System): If file system permissions have been changed, determine how they were altered. Was it done manually, or through Group Policy? This will guide you to the appropriate fix.

  3. Determine Registry Permission Changes: Next, check if registry permissions have been altered. If not, again, refer to the More Information section.

  4. Identify Change Method (Registry): If registry permissions have been modified, determine if these changes were made manually or via Group Policy.

  5. Verify Security Policy and Group Policy Preferences (GPPs): Specifically investigate Security Policy settings (configured via secpol.msc) and Group Policy Preferences (GPPs) as these are common mechanisms for managing permissions in a domain environment.

Determine if File System Permissions Have Been Changed

Examine the following folders to verify if the All Application Packages group has the required access rights. While most, but not all, subdirectories of Windows, Program Files, and WER inherit permissions, it’s crucial to check the main directories.

  • Program Files: Verify Read, Read & Execute, and List folder Contents permissions for the All Application Packages group.
  • Windows: Verify Read, Read & Execute, and List folder Contents permissions for the All Application Packages group.
  • Users\\AppData\Local\Microsoft\Windows\WER: Verify Special Permissions (List folder/read data, and Create Folders/Append Data) for the All Application Packages group.

Checking File Permissions

Determine if Registry Permissions Have Changed

Check the following registry keys using regedit.exe to ensure the All Application Packages group has Read permissions:

  • HKEY_CLASSES_ROOT
  • HKEY_LOCAL_MACHINE\Drivers
  • HKEY_LOCAL_MACHINE\HARDWARE
  • HKEY_LOCAL_MACHINE\SAM
  • HKEY_LOCAL_MACHINE\SOFTWARE
  • HKEY_LOCAL_MACHINE\SYSTEM
  • HKEY_USERS

Similar to file system permissions, most, but not all, subkeys of these registry keys should grant the All Application Packages group read access.

Registry Permissions

Determine if Group Policy Is Being Used to Manage Permissions

To ascertain if Group Policy is managing file system or registry permissions, follow these steps on an affected PC:

  1. Log in as Problem User: Sign in to the Windows PC as a user who is experiencing the Microsoft Store App launch issues.

  2. Open Command Prompt (Admin): Open an elevated command prompt (Run as administrator).

  3. Generate Group Policy Report: Execute the following command, replacing <path> with a local file path where you want to save the HTML report (e.g., C:\GPReport.html):

    gpresult /h <path>\gpreport.html

  4. Analyze Report: Open the generated gpreport.html file in a web browser. Navigate to: Computer Settings > Policies > Windows Settings > Security Settings. Look for File System and Registry entries.

    If File System or Registry entries exist under Security Settings, it indicates that Group Policy is being used to configure these permissions. You will need to modify the relevant Group Policy Object (GPO) to include the necessary permissions for the All Application Packages group.

Steps to Fix the Problem

The steps to resolve the issue depend on whether the file system and registry permissions were changed manually or through Group Policy.

Fix File System Permissions Changed Manually

If file system permissions were manually altered, follow these steps to restore the correct permissions:

  1. Open File Explorer.
  2. Navigate to C:\Program Files.
  3. Right-click the “Program Files” folder and select “Properties”.
  4. Go to the “Security” tab.
  5. Click the “Advanced” button.
  6. Click the “Change permissions” button.
  7. Click the “Add” button.
  8. Click the “Select a principal” link.
  9. Click the “Locations” button and select the local computer name.
  10. Enter “All Application Packages” in the “Enter the object names to select” field and click “Check Names”. Once resolved, click “OK”.
  11. Ensure “Type” is set to “Allow” and “Applies to” is set to “This folder, subfolders and files”.
  12. Under “Basic permissions”, check “Read & Execute”, “List folder contents”, and “Read”.
  13. Enable the checkbox “Replace all child object permissions with inheritable permission entries from this object”.
  14. Click “Apply” and then “OK”.
  15. Repeat steps 2-14 for C:\Windows.
  16. Repeat steps 2-14 for C:\Users, but grant the “All Application Packages” group “Full Control” instead of “Read & Execute”, “List folder contents”, and “Read” permissions.
  17. Click “Apply” and then “OK” to close all dialog boxes.

Fix File System Permissions Manually

Fix File System Permissions Changed by Group Policy

If Group Policy is managing file system permissions, a Group Policy administrator needs to perform the following steps:

  1. Open Group Policy Management Console (GPMC) - gpmc.msc.
  2. Locate the GPO: Find the Group Policy Object (GPO) identified in the “Determine if Group Policy is Being Used to Manage Permissions” section.
  3. Edit the GPO: Right-click the GPO and select “Edit”.
  4. Navigate to File System Settings: In the Group Policy Management Editor, go to: Computer Configuration\Policies\Windows Settings\Security Settings\File System.
  5. Edit or Create Entries:
    • If entries for C:\Program Files, C:\Windows, or C:\Users already exist, you can edit them.
    • If no entries exist, create a new entry for each path. To create a new entry, right-click “File System” and select “Add File”.
  6. Add “Program Files” Entry (if needed): If creating a new entry for “Program Files”, browse to C:\Program Files and click “OK”.
  7. Add Permissions: In the “Add a file or folder” dialog, click the “Add” button.
  8. Select Principal: Click the “Locations” button and select the local machine name.
  9. Add “All Application Packages”: Enter “All Application Packages”, click “Check Names”, and then “OK”.
  10. Grant Permissions: Grant the “All Application Packages” group Read, Read & Execute, and List folder Contents permissions.
  11. Apply Permissions: Click “Apply” and then “OK”.
  12. Enable Inheritance Replacement: Select the option “Replace existing permissions on all subfolders and files with inheritable permissions”.
  13. Repeat for “Windows” and “Users”: Repeat steps 6-12 for C:\Windows and C:\Users. For C:\Users, grant the “All Application Packages” group Full Control.
  14. Close GPMC: Close the Group Policy Management Editor.

Remember that Group Policy changes need time to replicate to all Domain Controllers and for client computers to update their Group Policy settings. You can force a Group Policy update on a client machine by running gpupdate /force in an elevated command prompt.

Fix Registry Permissions Changed Manually

If registry permissions were manually changed, use regedit.exe to restore the correct permissions:

  1. Open regedit.exe (Registry Editor).
  2. Right-click HKEY_USERS and select “Properties”.
  3. Verify “All Application Packages” has “Read” permission. If not, add the “All Application Packages” group and grant “Read” permission.
  4. Repeat step 2-3 for HKEY_CLASSES_ROOT.
  5. Expand HKEY_LOCAL_MACHINE.
  6. Check Subkeys: Check the following subkeys under HKEY_LOCAL_MACHINE: HARDWARE, SAM, SOFTWARE, and SYSTEM.
  7. Verify Permissions: For each subkey, ensure the “All Application Packages” group has “Read” permission. Add and grant permission if necessary.

Fix Registry Permissions Manually

Fix Registry Permissions Changed by Group Policy

If Group Policy is managing registry permissions, a Group Policy administrator should take these steps:

  1. Open Group Policy Management Console (GPMC) - gpmc.msc.
  2. Locate the GPO: Find the GPO identified in the “Determine if Group Policy is Being Used to Manage Permissions” section.
  3. Edit the GPO: Right-click the GPO and select “Edit”.
  4. Navigate to Registry Settings: In the Group Policy Management Editor, go to: Computer Configuration\Policies\Windows Settings\Security Settings\Registry.
  5. Add Registry Keys: Right-click in the right pane and select “Add Key”.
  6. Select CLASSES_ROOT.
  7. Add Permissions: In the “Database Registry Setting Extension” dialog, click the “Add” button.
  8. Select Principal: Click the “Locations” button and select the local machine name.
  9. Add “All Application Packages”: Add the “All Application Packages” group and grant them “Read” permission.
  10. Repeat for Other Keys: Repeat steps 5-9 for the following registry keys: Users, MACHINE\HARDWARE, MACHINE\SAM, MACHINE\SOFTWARE, and MACHINE\SYSTEM. Note that in GPMC, HKEY_LOCAL_MACHINE is represented as MACHINE.
  11. Close GPMC: Close the Group Policy Management Editor.

Again, remember Group Policy replication and update times.

More Information

For further details on related issues, refer to Microsoft Store Apps Fail to Start if the User Profiles or the ProgramData directory are Moved from their Default Location.

File System and Registry Access Control List Modifications

Windows operating systems, starting with Windows XP, employ tightened security permissions. Extensive modifications to default permissions are generally unnecessary and can be detrimental.

Significant discretionary access control list (DACL) changes can invalidate application compatibility testing performed by Microsoft. Such changes often lack the rigorous testing applied to default settings and can alter the fundamental behavior of the operating system in unintended ways. This can lead to application compatibility problems, instability, reduced functionality, and performance issues.

Modifying file system DACLs on operating system files in production environments is strongly discouraged. Any ACL changes should be carefully evaluated against specific threats to understand potential benefits in a particular configuration. Microsoft’s security guidance generally recommends minimal DACL changes, primarily for older systems like Windows 2000 where a few minor adjustments were sometimes necessary.

Extensive permission changes, especially those propagated throughout the registry and file system, are often irreversible. Once applied, they are difficult to fully undo. Even removing Group Policy settings that implemented DACL changes or attempting to revert to system defaults might not fully restore the original permissions, especially for newly created folders like user profile folders.

Changes to DACLs in the %SystemDrive% folder can lead to several negative consequences, including:

  • Recycle Bin malfunction and inability to recover deleted files.
  • Security reduction allowing non-administrators to view administrator’s Recycle Bin contents.
  • User profile failures and unexpected behavior.
  • Security reduction granting interactive users read access to user profiles.
  • Performance degradation due to excessive DACL edits in Group Policy, leading to slow logons or repeated restarts.
  • System slowdowns during Group Policy re-application cycles (approximately every 16 hours).
  • Application compatibility issues and crashes.

While Microsoft support will provide commercially reasonable efforts to help mitigate the worst effects of such permission modifications, a full rollback to the original state is often not possible. The only guaranteed way to return to the recommended out-of-the-box settings is to reformat the hard drive and reinstall the operating system.

Modifying registry DACLs, particularly across large portions of the registry hives, carries significant risk and can render systems non-functional. Even changes to individual registry keys should be carefully considered and thoroughly tested before implementation. Reformatting and reinstalling the operating system may be the only guaranteed recovery method in severe cases of registry permission corruption.

If you found this article helpful in resolving your Microsoft Store App launch issues, or if you have further questions or insights, please feel free to leave a comment below. Your feedback is valuable and helps us improve the quality and relevance of our content.

Post a Comment