The first step in my analysis was to review app deployment issues which are recorded in AppXDeployment-Server > Microsoft-Windows-AppXDeploymentServer/Operational event log in the hopes that they might provide some clues that could help me diagnose the cause of the problem.

In the event log, I noticed several entries with the event ID 5961 pointing at an COM App activation issue:

My next step was to determine what could cause this behavior. I knew from past customer engagements that "zero-bytes" file corruption is something that might happen during app updates on an irregular basis. On a hunch, I ran a PowerShell one-liner against package repository C:\Program Files\WindowsApp and sure enough, several files did not contain any data.

Get-ChildItem -Path "C:\Program Files\WindowsApps\" -Recurse | Where {$_.Length -eq 0}

The resulting output looked like this. Most critically, one of the dependency DLLs Microsoft.UI.Xaml.dll appeared to be corrupted:

    Folder: C:\Program Files\WindowsApps\Microsoft.UI.Xaml.2.1_2.11906.6001.0_x64__8wekyb3d8bbwe


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       17.06.2019     09:08              0 Microsoft.UI.Xaml.dll
-a----       17.06.2019     09:08              0 Microsoft.UI.Xaml.winmd
-a----       17.06.2019     09:08              0 resources.pri


    Folder: C:\Program Files\WindowsApps\Microsoft.Windows.Photos_2019.19051.16210.0_x64__8wekyb3d8bbwe\Assets\VideoTileAssets


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       08.08.2019     11:38              0 PhotosVideoEditorSquare44x44Logo.targetsize-24.png
-a----       08.08.2019     11:38              0 PhotosVideoEditorSquare44x44Logo.targetsize-24_altform-unplated.png
-a----       08.08.2019     11:38              0 PhotosVideoEditorWide310x150Logo.scale-200.png

Now that I had the possible cause, there was just one question left to answer: how could I fix this issue. One option would have been to copy affected files from a working system. Another was to force the Microsoft Store to repair damaged packages.

I chose the latter so I quickly put together a PowerShell script that could identify broken apps, then set the PackageStatus property for the affected packages (example path: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList\ Microsoft.Windows.Photos_2019.19051.16210.0_x64__8wekyb3d8bbwe\PackageStatus (DWORD)), which, when set to 2, indicates that the package is unusable and needs remediation, and finally trigger the Microsoft Store forcing it to re-download broken bits.

$DamagedPkgs = @()
$DamagedFiles = (Get-childitem -Path "C:\Program Files\WindowsApps\" -Recurse | Where {$_.Length -eq 0}).FullName
$BasePath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList\"

ForEach ($DamagedFile in $DamagedFiles) {
    If ($DamagedFile -like "*8wekyb3d8bbwe*") {
        $DamagedPkgs += ((Split-Path -Path $DamagedFile).Replace("C:\Program Files\WindowsApps\","") -Split ("8wekyb3d8bbwe"))[0] + "8wekyb3d8bbwe"
    }
}

ForEach ($Pkg in $($DamagedPkgs | Get-Unique)) {
    New-Item -Path $BasePath -Name $Pkg -Force
    New-ItemProperty -Path $($BasePath + $Pkg) -Name "PackageStatus" -Value "2" -PropertyType "DWORD" -Force  
}

#Trigger Microsoft Store to force remediation
Get-CimInstance -Namespace "Root\cimv2\mdm\dmmap" -ClassName "MDM_EnterpriseModernAppManagement_AppManagement01" | Invoke-CimMethod -MethodName UpdateScanMethod

I ran the script and after a brief moment of uncertainty I could start all broken apps again.

Using event viewer and PowerShell I had diagnosed and fixed the problem in a couple of minutes. What troubles me about this case is that an average user confronted with the same scenario would have had no way of knowing what was causing the app crashes or how to fix them. This is just one example of the many types of Windows issues that result in the “reinstall” mentality. Then again, I hope that Microsoft product group can make the whole AppX deployment model just a bit more resilient negating the need for the remediation in the first place.