Wednesday, 14 August 2019 13:36

The Case of Corrupted Store Apps

Written by
Rate this item
(4 votes)

image

A few days ago I began experiencing issues with built-in Windows apps where various apps would flash open and close straight away. Needless to say, this became very annoying very quickly. A few minutes with event viewer and PowerShell, however, and I not only determined the cause, but came up with a workaround.

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.

Read 24352 times Last modified on Wednesday, 14 August 2019 13:50

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