Thursday, 27 July 2017 13:33

The Case of Microsoft Edge Crash

Written by
Rate this item
(2 votes)


This case unfolds with a customer piloting Windows 7 to Windows 10 in place upgrade. It’s a really interesting case because it highlights the use of Sysinternals Process Monitor and PowerShell to identify and fix an issue and also because it is actually two cases in one.

It all started with a user complaining that Microsoft Edge wouldn't start on his upgraded system. We chalked it up to random issue caused by the inplace upgrade. We moved on, but a few days later multiple users started experiencing the issue.

Mark Russinovich always advises "when in doubt, run Process Monitor", so this is exactly what I did. I downloaded a copy from Technet and captured a trace of the faulty Microsoft Edge start.

Wondering if perhaps the sequence of processes starting during the Microsoft Edge start might reveal something, I opened the Process Tree dialog from the Tools menu. Focusing my attention on MicrosoftEdge.exe, I noticed that Windows Error Reporting (WER) service started a process named WerFault.exe around the time I tried launching Microsoft Edge.

Instead of looking for clues in the trace, I thought I might find clues by comparing the trace of the failing Edge to another captured on a system where the Edge broser starts successfully.

A few minutes later I had a second trace to compare side-by-side. Instead of scanning the several million events that had been captured, which would have been like looking for a needle in a haystack, my next step was to set the Include filter to MicrosoftEdge.exe. I also made an assumption that the issue was somehow related to registry, so I excluded all other types of events, and proceeded through the events in the trace from the failing system, correlating them with corresponding events on the working one.

Both traces had references to HKU hive, but to my consternation on the problematic machine those registry queries failed with ACCESS DENIED.

This confirmed my suspicions that the issue was caused by faulty registry permissions.

Further investigation showed that the group ALL_APP_Packages group was not present in the HKU hive, which in turn lead to Microsoft Edge to stop working. Confident I’d solved the mystery, I right-clicked the corresponding HKU hive and added the ALL_APP_Packages group.

I ran Microsoft Edge to verify my fix and to my immense satisfaction, the Edge browser started without a hitch.

The case wasn't closed yet though!

Somehow the registry permissions had been corrupted, so we had to figure out what was causing modifications to HKU registry hives permissions. I collected Process Monitor log of the HKU hive activity overnight. When I viewed the log, there was a clear pattern: a legacy line of business application was messing around with registry permissions. Why the application would modify default registry permissions will remain forever a mystery, but the important thing now was fixing the underlying issue using a two pronged approach. A patch was issued which disabled permisisons alterations. We still had to fix a number of systems out there, that were experiencing the issue. To do so, I simply wrote a PowerShell script that would add ALL_APP_Packages to the HKCU hive with read permissions. In order to support non-English systems I had to query actual group name using well known SIDs.

    Fixes ALL_APP_PACKAGES HKCU permissions.
	In order to support non-English systems the script queries actual group name
	using well known SIDs:
    SID: S-1-15-2-1, Name: ALL_APP_PACKAGES
    Description: All applications running in an app package context.
    Created:	 2016-11-12
    Version:	 1.0
    Author - Anton Romanyuk
    Twitter: @admiraltolwyn
    Blog   :
    This script is provided 'AS IS' with no warranties, confers no rights and 
    is not supported by the author.
	This script has to run in the user context!

# ---------------------------------------------------------------------------
# Global variables
# ---------------------------------------------------------------------------

# Detect language specific name of the ALL_APP_PACKAGES group
$SID= @("S-1-15-2-1")
$apps_sid = New-Object System.Security.Principal.SecurityIdentifier($SID) 
$apps_group = $apps_sid.Translate([System.Security.Principal.NTAccount]) -creplace '^[^\\]*\\', ''

# Find current user
$cur_user = [System.Security.Principal.WindowsIdentity]::GetCurrent().Name

$paths = ("HKCU:","HKCU:SOFTWARE")

# ---------------------------------------------------------------------------
# Set-RegistryKeyPermission:  Sets registry key permissions
# ---------------------------------------------------------------------------


Function Set-RegistryKeyPermission{
        [Parameter(Mandatory = $true)]
        [Parameter(Mandatory = $true)]
        [String]$InheritanceFlags = "ContainerInherit,ObjectInherit",
        [String]$PropagationFlags = "None",
    $aclRegistry= Get-Acl -Path $Path   
    $aclRegistry.SetAccessRuleProtection($true, $true)
    $ruleRegistry =  New-Object System.Security.AccessControl.RegistryAccessRule($Account,$RegistryRights,$InheritanceFlags,$PropagationFlags,$AccessControlType)
        If($Type -eq "Add")
            If($Type -eq "Remove")
                $aclRegistry.RemoveAccessRule($ruleRegistry) | Out-Null
        Throw $_.Exception.Message
    Write-Host "Setting $RegistryRights permissions for account $Account" -ForegroundColor DarkCyan
    Set-Acl -path $Path -AclObject $aclRegistry

# ---------------------------------------------------------------------------
# Main logic
# ---------------------------------------------------------------------------

ForEach ($path in $paths) {
    Write-Host "Settings READ permissions for account" $apps_group "on registry key" $path -ForegroundColor Green
    Set-RegistryKeyPermission -Path $path -Type "Add" -Account $apps_group -RegistryRights "ReadKey" -InheritanceFlags "None" -PropagationFlags "None" -AccessControlType "Allow"
	Write-Host "Settings FullControl permissions for account" $cur_user -ForegroundColor Green

The customer rolled out the script and the ongoing monitoring over the following week confirmed that the problem was gone.

With the help of Process Monitor, the case of the Microsoft Edge crashes was successfully closed.

Read 6840 times Last modified on Friday, 28 July 2017 16:25
More in this category: The Case of 'Something Went Wrong' »

Recent Posts

  • Windows 10 21H2 Built-In Apps: What to Keep
    The development of the Windows 10, version 21H2 is finished and the update will soon be available for download from…
    Written on Wednesday, 20 October 2021 11:41
  • Group Policy Changes in Windows 10 21H2
    As Windows 10, version 21H2 update development winds down, Microsoft is now preparing for the final release of the Windows…
    Written on Wednesday, 20 October 2021 07:20
  • Group Policy Changes in Windows 10 20H1 Preview
    As Windows 10 Vibranium Update (20H1) development winds down, Microsoft is now beginning the phase of checking in the final…
    Written on Tuesday, 14 January 2020 04:51
  • An alternative ESU MAK Activation Solution
    This blog post was shared with me by a colleague of mine, Daniel Dorner, a Microsoft Premier Field Engineer. It’s…
    Written on Wednesday, 04 December 2019 21:04
  • The Case of Missing UE-V Templates
    My customers often deal with unexpected Windows behavior and this case is no different. This particular one is especially interesting…
    Written on Tuesday, 03 September 2019 12:20
  • The Case of Changing Default Printer
    While I sometimes long for the day when I no longer have to deal with unexpected Windows 10 behavior, there’s…
    Written on Wednesday, 14 August 2019 20:36