Bug 122134 - LibreOffice instlaller msi attempting to install KB2999226 on windows 10 machine.
Summary: LibreOffice instlaller msi attempting to install KB2999226 on windows 10 mach...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
6.1.3.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.3.0 target:6.2.0.1 target:6.1.5
Keywords:
Depends on:
Blocks: Installer-Windows
  Show dependency treegraph
 
Reported: 2018-12-16 02:50 UTC by Mitchell
Modified: 2018-12-20 13:11 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mitchell 2018-12-16 02:50:31 UTC
Description:
While attempting to install LibreOffice 6.1.3 (https://www.libreoffice.org/donate/dl/win-x86_64/6.1.3/en-US/LibreOffice_6.1.3_Win_x64.msi) the installation fails and rolls back. After creating a MSI installer log I tracked down the issue to a Microsoft update attempting to be installed when installing LibreOffice (https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows). Windows update is "disabled" on the machine in question. I understand that LibreOffice cannot be installed if certain prerequisites are not met however the KB in question is not applicable to my machine which is running Windows 10 build 1803. Can it be changed to only attempt to install the update on non Windows 10 machines? I am not intimately familiar with MSI installers so I am not sure if a condition can be set so that the update is only attempted to be installed on the applicable operating systems.

Steps to Reproduce:
1.Stop the "wuauserv" service and disable it through the registry (start=0x4)
2.Remove permission from the start key in HKLM\system\currentcontrolset\wuauserv so that no modifications can be made to the start key.
3.Run the LibreOffice installer.

Actual Results:
Installation fails and rolls back.

Expected Results:
Installation success 


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Aron Budea 2018-12-16 04:06:25 UTC
Mike, what are your thoughts on this?
Comment 2 Mike Kaganski 2018-12-16 10:58:54 UTC
Short version: this is the direct result of https://git.libreoffice.org/core/+/1882827320ed760de82211cf690b686f8d34ff74.

TLDR version:

Yes, since the commit above, the installation of KB2999226 is attempted on all supported Windows platforms, unconditionally. The reason for this follows.

First, the discussion of dependency on the KB (i.e., on UCRT) is given in bug 108580 comment 60. There, it's explained why do we now embed the KB installer in the MSI in the first place.

When we did that, we discovered that the awkward decision of MS to only provide UCRT for Vista+ as MSU has made many other applications to look for ways to install it, just as we struggle with that. And many of those do that wrong. They install UCRT improperly, so that it allows them to run; but for LibreOffice, the wrong installation is enough to detect it, but insufficient to operate. We discovered that at least Avast antivirus does that, so we have a number of reports when LibreOffice failed to run after installation on system with Avast preinstalled: see bug 119910.

So the solution was to remove the check for the presence of UCRT. Now we simply try installing the UCRT MSU unconditionally. What does it mean? It means that we depend upon Windows Installer service (because MSU is Windows Installer package); and we check the return value of the installation. If we get that the update is not applicable for the system, we just continue. But errors make the installer to fail; and disabling the Windows Update generates one such error.

Actually, our installer knows how to temporarily enable a disabled Windows Update service, *if it was disabled in a usual way* (its startup type set to "Disabled" in Service Manager). But we don't provide a solution for any advanced technique to disable the service (which users sometimes have to do because of other MS interesting decisions about their update policy, which is outside of this discussion).

Well - but the update is not required on Windows 10; so why just not skip it based on the Windows version?

You won't believe, but the problem here is just one of the ~recent decisions Microsoft has made about WinAPI; and that decision is IMO one of the most idiotic ones ever made. It's about getting Windows version information; [1] now the WinAPI dedicated to obtaining Windows version (GetVersion) is deprecated, and - what's most important - returns lies! It doesn't tell you that you are running on Windows 10, unless you explicitly include a manifest in your application that it supports Win10. The reasoning behind the change was no less idiotic: because *some* developers made mistakes checking versions improperly, now all developers (including those who do it properly) should suffer.

Well - we do include such manifest into LibreOffice executables. Isn't that enough? Unfortunately, no. When installing the application, the executable running is not one of LibreOffice executables; it's Windows Installer component named msiexec.exe (a part of Windows OS) that is running and performing all the checks and actions recorded in MSI. And guess what? Believe it or not, but the msiexec.exe in Windows 10 does *not* include a manifest about its compatibility with Windows 10! The Windows component responsible for installation of packages does not contain what is required to get the accurate Windows version information! It only declares compatibility with Windows 8.1 in the manifest, so you get Windows 8.1 when you check the version in the installer!

When MS had introduced the change in version API, it had published a workaround on its GetVersion documentation page. The workaround consisted of getting version of a system file (kernel32.dll) instead. And initially, it worked. But then, in some Windows 10 update, they decided that they made life of developers too easy, and had made another step in the direction of hiding version information from us. And that last step (I don't know if and where it was published) was the most astonishing in its consequences. They altered the API for getting file versions (at least in Windows Installer) to also not return version numbers greater than Windows version specified in their msiexec.exe. What does it mean in reality? Well - it means that if your application depends upon a file with version like 12.X, you will *never* get the correct version in your MSI check, because msiexec.exe will report version 6.3 (the internal version of Windows 8.1) for that file! No matter what that file was. No matter if the file versioning is independent of OS versioning.

And now, if you check for UCRT DLL version on Windows 10, you will get 8.3, although it had never had that version! The very first release of the library had version 10.X already. I simply don't see a reliable way to detect that we run on Windows 10 from installer, to conditionally avoid some steps (installing the KB in this case).

Does that mean that there's nothing to be done here?
No. First, in https://git.libreoffice.org/core/+/46a5440daea1d65bd4e2f3b2793098bea9f8c907, I had changed the MSU installation process to not fail on errors related to inability to start the service - see bug 121987. So, in the next LO version installer, some such cases will not lead to the problem. But not all: if the service is not disabled, but run with reduced permissions, which results in failed installation - contrary t failed service startup - the installation will still fail. Additionally, if the service was disabled on a Win7 with UCRT absent, the solution will lead to that "Cannot run LibreOffice, api-ms-win-crt-runtime-l1-1-0.dll is missing" error later when attempting to run LO.
Thus, I am working on another patch - https://gerrit.libreoffice.org/64874 - which will never fail installing the MSU, but will emit a warning about that instead. That will at least prepare users that something *might* go wrong later, but will not prevent them from completing the installation.

And that last solution will still emit those warnings on Windows 10 (where it shouldn't in theory), because of that difficulty to get the OS version I discussed above. If someone has an idea how to solve the version problem, I'd be most thankful!

If you are still with me at tgis point, all I can say is thank you for reading this!

[1] https://docs.microsoft.com/en-us/windows/desktop/w8cookbook/operating-system-version-changes-in-windows-8-1
Comment 3 Mitchell 2018-12-16 15:44:22 UTC
Thanks for the reply. Seems I have hit upon a hot button issue ;). You have probably considered this but I will put it here anyway for completeness. The "OS Name" is stored in a registry key located at "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion". Also there are "CurrentMajorVersionNumber" and "CurrentMinorVersionNumber" which replace the "CurrentVersion" key in at least Windows 10 and perhaps 8. Would it be possible to query these keys and reliably detect the presence of a Windows 10 machine?
Comment 4 Mike Kaganski 2018-12-16 16:22:13 UTC
(In reply to Mitchell from comment #3)

I'll possibly try that. Although CurrentVersion doesn't work, CurrentMajorVersionNumber could do. Thanks for the suggestion I actually didn't consider!
Comment 5 Mitchell 2018-12-16 16:29:13 UTC
Nice to know I can contribute in some way. I do IT for a living and sometimes need to know the Windows version from a computer the will not longer even attempt to boot. Mounting the registry hive and looking in that key was my solution to the problem so I though I would throw that out there.
Comment 6 Mike Kaganski 2018-12-16 21:32:09 UTC
https://gerrit.libreoffice.org/65231
Comment 7 Commit Notification 2018-12-17 04:23:08 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/d87fa557ff58c3b9f5c9079a1d7595e095694111%5E%21

tdf#122134: use CurrentMajorVersionNumber to filter out Windows 10

It will be available in 6.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 8 Commit Notification 2018-12-17 12:20:25 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-2":

https://git.libreoffice.org/core/+/4a8677150c428855cd67c71341b6bb6d07b59f84%5E%21

tdf#122134: use CurrentMajorVersionNumber to filter out Windows 10

It will be available in 6.2.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2018-12-20 13:11:40 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

https://git.libreoffice.org/core/+/72f2fbc75dc254ea8e13527b592bd0b4fb946bab%5E%21

tdf#122134: use CurrentMajorVersionNumber to filter out Windows 10

It will be available in 6.1.5.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.