Bundle installers fail to install, "0x80070001 - Incorrect function"

[mscrivo]

Steps to reproduce

Download the WindowsDesktop installers from:
https://dotnetcli.blob.core.windows.net/dotnet/Runtime/release/3.0/windowsdesktop-runtime-latest-win-x64.exe
https://dotnetcli.blob.core.windows.net/dotnet/Runtime/release/3.0/windowsdesktop-runtime-latest-win-x86.exe

and run them

Expected behavior

Installer should install successfully

Actual behavior

Error during installation:

Environment data

Microsoft_Windows_Desktop_Runtime_-3.0.0(x64)_20190823100101.log

[dagood]

Reproduces for me too. Also:

• Repros with the .NET Core Runtime bundle installer.
• Repros in master and the latest release/3.0-preview9 build.

Important-seeming bits of the logs:

[0A84:1814][2019-08-19T08:08:29]e000: Error 0x80070001: Failed to extract all files from container, erf: 1:2:0
[0A84:1B4C][2019-08-19T08:08:29]e000: Error 0x80070001: Failed to wait for operation complete.
[0A84:1B4C][2019-08-19T08:08:29]e000: Error 0x80070001: Failed to open container.
[0A84:1B4C][2019-08-19T08:08:29]e000: Error 0x80070001: Failed to open container: WixAttachedContainer.
[0A84:1B4C][2019-08-19T08:08:29]e312: Failed to extract payloads from container: WixAttachedContainer to working path: C:\Users\dagood\AppData\Local\Temp\{E3F2E108-FBE6-4EB4-A15F-FEF87506090C}\36994DD10E999072EEDEFDA5D17C37D00946408A, error: 0x80070001.
[0A84:0AB0][2019-08-19T08:08:29]e000: Error 0x80070001: Cache thread exited unexpectedly.
...
[0A84:0AB0][2019-08-19T08:08:30]i399: Apply complete, result: 0x80070001, restart: None, ba requested restart:  No
[0A84:0AB0][2019-08-19T08:08:34]i500: Shutting down, exit code: 0x1

(The MSI isn't successfully extracted and started, so the bundle log is the only one.)

Reproduces on earlier builds too, e.g. x86 and x64 WD installer outputs from https://dev.azure.com/dnceng/internal/_build/results?buildId=320694.

Opening up the bundle in BurnBundleReader, I can take out the MSI fine, and it's the right size and has the same checksum as what's listed in manifest.xml.

@joeloff do you have any ideas what's going on?

I'm going to try to find the cutoff point for this issue in build outputs.

/cc @dleeapho @mmitche

[dagood]

Last OK 3.0-preview9: dotnet-runtime-3.0.0-preview9-19419-06-win-x64.exe
First failure 3.0-preview9: dotnet-runtime-3.0.0-preview9-19420-02-win-x64.exe

[dagood]

Looks like the changes to introduce the WD bundle caused the MSIs inside the bundle to no longer get signed. I don't know how to solidly connect that to the error--I checked because of wixtoolset/issues#5716 (comment). I do know they should be signed, though.

[dagood]

Looks like a typo in the item type that the MSI signing proj is meant to depend on, causing it to run too early and miss the runtime MSIs. Trying out a fix.

[joeloff]

Was the bundle engine signed? Typically the signing process is to sign the MSIs, build the bundle. Then use Insignia to extract the bundle engine, sign that EXE, attach the engine back to the bundle with insignia and then sign the bundle EXE

[dagood]

Not sure how to tell for sure, extracting the engine from the good and bad bundles give me unsigned EXEs. (But it would make some sense if the cert weren't extracted by the tool, since usually the engine is extracted in order to sign it anyway.)

I poked through the logs to try to check that way, and it looks like there are a few issues there too--attaching not finding the right project files, and the WindowsDesktop extract/attach using dotnet-runtime naming rather than windowsdesktop-runtime. Looking into it.

[joeloff]

This is very likely an issue with not signing the bundle engine, e.g. http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Burn-3-8-1128-Error-0x80070001-Failed-to-extract-all-files-from-container-erf-1-2-0-td7593695.html

[dagood]

I think you're right, signing the MSIs alone doesn't cause the error to change. (I kicked off a validation build with only this change before I spotted more issues.)

The build log shows that the reattachment target doesn't actually run, so yeah, although I don't know how to see it from the end results, the engine isn't signed. I have a build running that should have this fixed to test out.

[dagood]

dotnet/core-setup#7820 fixes this, installers from validation build are signed, contain signed MSIs, and install properly.

[dagood]

The fix is now merged in all the affected branches, and the 3.0 latest download links give me working installers now. Thanks for trying out the installers and reporting this, @mscrivo. 😄