App Installer emitting a "Unknown error (0x80D05011)" on some machines

[nbevans]

Similar to #186 - but a different error code. Also, with this error code - the workaround to use Add-AppxPackage via PowerShell does not work. So the .appinstaller cannot be installed at all on machines that exhibit this issue - we are unsure currently what to advise to the customer short of "try reinstalling your machine from scratch".

Here is a Feedback Hub link to captured diagnostic data when attempting to install via App Installer: https://aka.ms/AAa0oga

[nbevans]

So an update on this.

We had the customer reboot the machine. We then tried to install the app again but this time the App Installer was producing error code of 0x8000FFFF (which is the same as #186) however it had a different error text which did not say "Catastrophic error". We then tried the Add-AppxPackage workaround and hey-presto it worked, the app was successfully installed.

There are a lot of weird bugs in the App Installer architecture...

[nbevans]

I have now witnessed this error on my own machine and/or VM's, several times over the last week or so.

Simply rebooting the machine and trying again resolves it every single time.

[FreddyDgh]

I am seeing this error frequently as well, and have found it difficult to diagnose.

[wjrivera]

Any word on possible solutions for this?

[samiranshah-zz]

Hi @nbevans, are you still seeing this issue? Is your scenario same as #186?

[samiranshah-zz]

Closing this. Please reopen if you are still seeing the issue.

[nbevans]

@samiranshah Sorry I missed this. Yes I saw this issue ("Unknown error") again just a couple weeks ago. A reboot of the machine fixed it.

[wbokkers]

We saw this issue today. A reboot did not fix it, unfortunately.

[yowl]

@samiranshah Please reopen as we are also seeing this after changing the version number from 1.0.xx.yyy to 1.1.0.0

A reboot did fix it here.

[mikehearn]

I've spent a few hours debugging this. Here's what's going wrong and how to work around it.

This looks like a (very serious!!) bug in the MSIX / Delivery Optimization subsystem of Windows. It appears Microsoft already know about it and have fixed it back in May, but haven't yet released the fix, at least not to Windows 10.

@wcheng-msft @samiranshah You guys need to document the bug and publish an official workaround if you aren't going to push out the fix ASAP because this is a nightmare to figure out, yet you clearly already know what the bug is! That's really not a satisfying discovery.

The Delivery Optimization subsystem that is used by App Installer appears to be incorrectly caching the size of the file given a URL, in memory. If an .appinstaller file changes its size once published, then any machine that already downloaded it will try to download the exact same number of bytes as previously retrieved until the in memory cache is cleared with a reboot. This will result in one of two things happening:

1. Windows requests more bytes than actually exist in the file, and then thinks - wrongly - the server doesn't support Range queries when it doesn't get enough bytes. It reports error 0x80D05011 which is "DO_E_INSUFFICIENT_RANGE_SUPPORT" as a consequence.
2. Windows requests fewer bytes than actually exist, resulting in an attempt to parse truncated XML. This can show up in a variety of ways.

@yowl This is why you see the failure once you changed the version number. The problem is not actually the change of version number but rather that the new version quad is a different size textually to the previous.

The situation may be complicated by HTTP redirects. I saw this problem myself before ever changing anything about the XML, and I think Windows cached the wrong size from the body of a 302 redirect from HTTP to HTTPS. So watch out for that if your server generates a lot of HTML when issuing redirects.

You can see that this bug is happening by dumping the Delivery Optimization subsystem logs: Get-DeliveryOptimizationLog | Set-Content c:\dosvc.log then look at the end. If you study it very carefully you will notice that the size of the request that is being made is different to the actual size of the file on your web server.

Here's a stupid hack that seems to work:

1. Always pad the appinstaller.xml file with white space to a fixed size large enough that you'll never exceed it. If your XML grows, it'll eat into the white space which the XML parser will ignore. If it shrinks, add more whitespace to re-pad it to the old length. I'm generating the AppInstaller .XML myself rather than using any Microsoft tool so I can do this easily - if you aren't then you may need a custom script.
2. Always embed the version number into the MSIX file name and never re-use a version after the package was uploaded. This will ensure Windows never sees one package URL with different sizes.

(edited for clarity)

[yowl]

Thanks @mikehearn . Here's some powershell that I'm putting into my pipeline to do as you suggest

$size=(Get-Item "$($args[0])").length
Write-Host $size
$padSize=2000 - $size
Write-Host padding with $padSize
$padString = "".PadRight($padSize)
Add-Content "$($args[0])" $padString -NoNewline