Today I’m going to share an experience I had with troubleshooting random UWP application crashes on my Windows PC. My friend had just installed Windows RC on his laptop, on a new partition – so it was a fresh install and not an upgrade. The reason why I asked him to do this, is because many times, upgrades may cause issues like random freezes and crashes, for no apparent reason. I’ve seen a lot of cases with Windows XP or Windows Vista upgraded to Windows 7 – so I always recommend users to perform a clean install rather than an upgrade.
Windows Store App Crashes
In spite of a clean install, Windows Store apps were crashing. So my first hunch was to disable all security software that was running on the machine since it tends to sometimes interfere with Windows applications that are trying to connect to the Internet. This may lead to freezing and crashes of such UWP applications. Sometimes just disabling Internet security software will not fix the problem. We may need to disable it from Startup and stop all the related services and reboot to completely rule out that problem. Sadly that had no effect on the problem.
So my next step was to perform a Clean Boot i.e. disable all non-Microsoft related startup items and reboot the system. This can rule out if any other application is interfering with the Windows 8 applications. I used the method described in this post on how to Manage Startup Items to do so. Sadly this didn’t help much. But when you’re troubleshooting App crashes this is an important step to try, even if Clean Boot did not help in this case.
My next step was to run the system file checker to see if any operating system files had been corrupted. Sometimes users tend to use tweaking software or system file patches that could corrupt the core windows files, which can lead to stability issues on Windows. The SFC scan reported that there weren’t any problems found. But even if the result said so I had to check the logs to confirm it. I have seen cases where SFC reports that there are no issues found, and still we get to see corrupted files or registry entries in the log files, which we need to manually fix. So I followed the steps provided in this post on how to analyze SFC logs, but strangely the logs seemed to be clean.
Then I had to go back to the basics. There are a few other things that could cause Windows apps to not work. I followed this post on how to fix Tiles are not responding and checked if UAC was disabled, Screen resolution of the Monitor, New Windows user account, etc. Nothing helped. I know, as a last resort I may need to have him reinstall his Windows. But I couldn’t give up so easier I never considered reinstallation of Windows as a good troubleshooting step, there is nothing like troubleshooting a complicated issue and exhausting all the available resources.
Operating System 5 errors
So I researched all Internet, started reading all the Event logs and app crash dump files. I found something interesting, there are few Operating System 5 errors; which means that there are some permission issues going on. Seems like the user had messed up the C drive permissions.
I can’t remember how many times I have advised users not to change the permission or any attributes of the root C folder; because that’s where all the boot related files and all the system files are located.
If you want to change the permission, change a specific folder or file and not the whole C drive. Anyway, I searched online for the appropriate permissions required for the Windows application to run properly. Luckily I found a TechNet article about Managing Client Access to the Windows Store. In that article, it’s mentioned-
While configuring the access permissions on any of these resources, it is important to identify which of these resources grants access to all Metro style apps and ensure that the new effective permissions do not remove that access. When supplying the permissions in SDDL form, the security identifier (SID) for ALL APPLICATION PACKAGES is S-1-15-2-1.
So I went and gave “ALL APPLICATION PACKAGES” permission to root C folder and rebooted the system. Voilà no more crashes it worked just fine!
This is one of the most interesting and challenging troubleshooting cases I have done in quite some time. It feels really good when you do so successfully.
Shyam aka “Captain Jack” is a Microsoft MVP alumnus and a Windows Enthusiast with an interest in Advanced Windows troubleshooting. Suggestions made and opinions expressed by him here are his personal one's and not of his current employers. He blogs at captaindbg.com.