Wednesday, 14 August 2019 13:36

The Case of Corrupted Store Apps

Written by
Rate this item
(0 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 1652 times Last modified on Wednesday, 14 August 2019 13:50
  1. Comments (5)

  2. Add yours
This comment was minimized by the moderator on the site

Anton - thanks so much for this. We've seen this in our environment several times and have struggled for a fix. We are able to mark apps as NeedsRemediation, but are having problems triggering the remediation itself. When calling the...

Anton - thanks so much for this. We've seen this in our environment several times and have struggled for a fix. We are able to mark apps as NeedsRemediation, but are having problems triggering the remediation itself. When calling the UpdateScanMethod, it looks like it errors out with an unspecified error; upon further digging it looks like the error we are receiving is a "A specified logon session does not exist. It may already have been terminated." We are in an environment where the user does not have the ability to call the method and it must be done from a separate Admin powershell window. Any pointers? Do you know of any other ways to trigger the remediation step?

Cheers,
Chris

Read More
Chris Moore
This comment was minimized by the moderator on the site

My assumption is that the remediation will get triggered once the Microsoft Store component will initiate an app update download. It will just take longer.

As far as the error message goes: could it be something specific to your environment? A...

My assumption is that the remediation will get triggered once the Microsoft Store component will initiate an app update download. It will just take longer.

As far as the error message goes: could it be something specific to your environment? A quick google search shows several hits for possible causes, including this one. Keep in mind that the described workaround will only work for one specific type of error. I've seen other possible failure scenarios which require a slightly different approach. As a matter of fact - as I am trying to find a common denominator - is your environment behind a proxy?

Read More
Anton Romanyuk
This comment was minimized by the moderator on the site

As a matter of fact - as I am trying to find a common denominator - is your environment behind a proxy?


Hey Anton - Yep! Behind a proxy. Cisco WSA, explicit forward, non-transparent. Anonymous auth for majority of web traffic.

It's super weird....

As a matter of fact - as I am trying to find a common denominator - is your environment behind a proxy?


Hey Anton - Yep! Behind a proxy. Cisco WSA, explicit forward, non-transparent. Anonymous auth for majority of web traffic.

It's super weird. We're about 1600 machines into Win10 and somewhere around 300 of them have various store app DLLs as 0-byte size, most are the UI.XAML dll mentioned here. We've deployed the NeedsRemediation regfix as above to a dozen or so; some machines fix themselves after awhile as you expected. Some machines that have remediated previously have the problem recur eventually.

Read More
Chris Moore
This comment was minimized by the moderator on the site

I should note we have whitelisted the following URLs from the built-in WSA antimalware engine:

.tlu.dl.delivery.mp.microsoft.com, .au.windowsupdate.com, bspmts.mp.microsoft.com, download.microsoft.com

Chris Moore
This comment was minimized by the moderator on the site

Hi Anton,

Thanks for this, it's a much better solution than what we were going for (copy over the corrupted files). We had this problem for a while now and I can confirm it was proxy related. I don't know exactly what was whitelisted as I'm not...

Hi Anton,

Thanks for this, it's a much better solution than what we were going for (copy over the corrupted files). We had this problem for a while now and I can confirm it was proxy related. I don't know exactly what was whitelisted as I'm not the proxy guy, but the problem disappeared. The adresses Chris Moore mentioned are probably a good start.

Read More
Roger Moquin
There are no comments posted here yet

Leave your comments

  1. Posting comment as a guest.
0 Characters
Attachments (0 / 3)
Share Your Location

Recent Posts