Created attachment 134077 [details]
error msge and two different system configuration

This is not a LibreOffice problem. There's a plausible solution to the problem here: https://www.smartftp.com/support/kb/the-program-cant-start-because-api-ms-win-crt-runtime-l1-1-0dll-is-missing-f2702.html

(In reply to Xisco Faulí from comment #2)

Xisco, I'm not sure it's NOTOURBUG. As I described in bug 108005 comment 16, since 5.4 there are *a lot* of these errors. And the problem is that we bundle the necessary libraries with LO! You may check that using, e.g., 7-zip and opening our MSIs with it, and see that the problematic file is there. We even had a story with runtime for VS 2015 that we couldn't bundle for some time: see https://wiki.documentfoundation.org/Development/msvc-x86_64#VC_Runtime_Install_Error_.28FIXED.2C_keep_for_ref.29

Let's keep this open until we actually find out what's going on, or at least until the reports stop coming in.

*** Bug 111628 has been marked as a duplicate of this bug. ***

*** Bug 109994 has been marked as a duplicate of this bug. ***

This is where Visual C++ 2015 Redistributable Update 3 has to be installed from:
https://www.microsoft.com/en-us/download/details.aspx?id=53840

As documentation states, [1] if a directory name *starts with* one of predefined SystemFolder properties, a CustomAction type 51 is generated for it. "It does not verify that the directory name exactly equals the directory property. Any directory beginning with one of these standard folder names gets a type 51 custom action, even if the rest of the name is not a GUID."

Our fix for bug 105311 follows this description literally. But my concern is if we are victims of another MS documentation flaw. I mean, the passage "The tables in the merge module must reference the location of a child directory of TARGETDIR, *or another directory in the merge module's tree*" in the mentioned documentation page (emphasis mine).

The C-Runtime merge module has two directories in it, named

SystemFolder.E281B893_10D7_34CE_BB0E_B69D88E154A5
and
SystemFolder_x86_VC.E281B893_10D7_34CE_BB0E_B69D88E154A5

The former has its parent set to TARGETDIR, and the latter has its parent set to former (SystemFolder.E281B893_10D7_34CE_BB0E_B69D88E154A5). I.e., they form a hierarchy (though the latter doesn't define any subdirectory).

But we generate two custom actions for both of them, because they both do begin with "SystemFolder". Thus, we may break the hierarchy (that's my guess). Intuitively, this shouldn't break things, as we still point both to a proper location, but who knows.

Could it be that MS documentation must be read as "if directory name *before dot* is equal to one of pre-defined SystemFolder properties, ..."?

Adding David Ostrovsky (the author of fix for bug 105311, and expert in this area) to CC list.

[1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa367787

Created attachment 135448 [details]
Install log for an installation resulted in non-functional program

This is an installation log taken on a freshly-installed Windows Server 2008 Version 6.1 (Build 7601: Service Pack 1), no updates, with command line

msiexec /i C:\Users\Administrator\Downloads\LibreOffice_5.4.0.3_Win_x86.msi /l*vx C:\Users\Administrator\Downloads\LOinst.log

The installation completed successfully, and then launching the program resulted in the mentioned error message:

---------------------------
soffice.exe - System Error
---------------------------
The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem. 
---------------------------
OK   
---------------------------

The problem is condition for component "ucrtbase.dll_system_x86.E281B893_10D7_34CE_BB0E_B69D88E154A5", which is

((VersionNT = 501) OR (VersionNT = 502)) AND (VC_REDIST=1)

This is only true for WinXP systems. So, I assume that the problem is only with Vista+ systems that have no Universal C Runtime preinstalled (up to Windows 10?). Changing the condition to simple

VC_REDIST=1

allows me to install and run LibreOffice on the above-mentioned test system.

Searching for "VersionNT" over repository doesn't give any similar results, I assume that this comes from merge module itself.

The Microsoft Visual C++ 2015 Redistributable Update 3 download page references KB 2999226 [1], which tells about different Universal C Runtime packages for different Windows versions. This makes me think that there might be different merge modules for different Windows versions, that we might need to include into installer, each one with its own VersionNT condition. I am not sure that simply forcing the WinXP version (that we bundle now) to install on any Vista+ is a proper solution.

[1] https://support.microsoft.com/en-us/kb/2999226

Sigh.

A discussion in a blog by Visual C++ team [1] describes this in detail.

> On Windows Vista and newer operating systems, the Universal CRT is
> installed via Windows Update—either when the machine downloads new
> updates from the web or when you install one of the redistributable
> packages from the Download Center (the November build, 10586, can be
> found here:
> http://www.microsoft.com/en-us/download/details.aspx?id=50410).
> Windows Update redistributables do not use MSI; they have a different
> installer technology. Because they do not use MSI, there are no MSMs
> for the Universal CRT. For Windows Vista and newer, installation of
> the Windows Update packages is the only supported way to get the
> Universal CRT onto the machine in the system directory. The Visual C++
> libraries MSMs install the Universal CRT on Windows XP only because
> the Universal CRT is not an operating system component on Windows XP
> (and Windows XP does not support the same Windows Update packaging
> mechanisms that are used on Windows Vista and above). Do not modify
> the MSMs.

So, it turns out that we cannot bundle the Universal CRT with the installer. In that case, we have a hard external dependency on those systems, that we must mention on release notes page. And possibly on the download page, with a link to MS site (mentioned in comment 7).

[1] https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/

Or can we?

On the same page mentioned in comment 11:

> 6. Updated September 11, 2015:  App-local deployment of the Universal CRT is
> supported.  To obtain the binaries for app-local deployment, install the
> Windows Software Development Kit (SDK) for Windows 10.  The binaries will be
> installed to C:\Program Files (x86)\Windows Kits\10\Redist\ucrt.  You will
> need to copy all of the DLLs with your app (note that the set of DLLs are
> necessary is different on different versions of Windows, so you must include
> all of the DLLs in order for your program to run on all supported versions
> of Windows).

Is this serious enough to escalate Importance to major? Most Windows users meeting this problem will likely not be able to solve it on their own.

While a solution is being discussed, I suggest placing a prominent note on the Windows download page on the requirement. Those who rather not deal with this issue on their own should go for the Still version for now.

(In reply to Aron Budea from comment #7)
> This is where Visual C++ 2015 Redistributable Update 3 has to be installed
> from:
> https://www.microsoft.com/en-us/download/details.aspx?id=53840

Somehow this didn't work for me. Neither did Still version: 5.3.6.
I've opted to return to 5.2.5.1, and will stay on until this bug is resolved.

(In reply to Libomark from comment #16)
> Anyone coming new to LO would likely just give up and look for something
> else: failed installations are IMHO a critical error - nothing works.

I agree. Can we have this escalated to critical?

It seems that 2015+ vcredists aren't MSI-dependent (rather, they contain MSU packages in it, which require wusa.exe to run).

Maybe these packages won't conflict with MSI process, and thus, will allow us to run from installer? We could try to package the vc_redist.exe to out MSI, and run it in case a pre-requisite fits (OS + absence of the redist)?

We are monitoring emails sent to the download@libreoffice.org address, where users can send questions, and we are getting this a lot. We could set up the auto-responder to point people here: https://www.microsoft.com/en-us/download/details.aspx?id=52685

Or is a fix in preparation for an upcoming release?

Thanks

(In reply to Mike Saunders from comment #19)
> 
> Or is a fix in preparation for an upcoming release?

From speaking to Cloph, it looks like this will be fixed by bundling the DLL in 5.4.3 onwards.

Christian Lohmaier committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=71d9a61302e65fe091cf70c13fa72b3df09b7e3a

tdf#108580 ship universal crts with the program as workaround

It will be available in 6.0.0.

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

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

Christian Lohmaier committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=67940d53fd68283c7dbc70897063c33d5ede49df&h=libreoffice-5-4

tdf#108580 ship universal crts with the program as workaround

It will be available in 5.4.4.

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

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

Christian Lohmaier committed a patch related to this issue.
It has been pushed to "libreoffice-5-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2c5875485dd53c9e6d509ffa474212fadb8cefed&h=libreoffice-5-4-3

tdf#108580 ship universal crts with the program as workaround

It will be available in 5.4.3.

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

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

.

What are the dll to copy to get installed 5.4.2.2 from 5.4.2.2 portable?

(In reply to Boris Silva R from comment #25)
> What are the dll to copy to get installed 5.4.2.2 from 5.4.2.2 portable?

For now i copy all api-ms-win-***.dll fron the LibreOfficePortable\App\libreoffice\program to the installed LO 5.4.2.2 and get it working in Win7 (no sp1)

Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=61b1d631331551b43bc7d619be33bfbfeff7cad6

tdf#108580: integrate vc_redist.exe into MSI

It will be available in 6.1.0.

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

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

Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ca893ce3e4da351576e0d57caada57da190773f2&h=libreoffice-6-0

tdf#108580: integrate vc_redist.exe into MSI

It will be available in 6.0.0.2.

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

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

https://techfries.co/fix-api-ms-win-crt-runtime-l1-1-0-dll-missing-system-error/

Hi guys, I just downloaded 6.0.0.3 and installed it over 5.3.x and it seems the problem is still not solved. I get the same error message as the OP, so I tried to:

1) Repair the installation – no success
2) Remove LO and Visual C++ Redistributable for VS 2015 and perform a fresh install – no success although I saw the Visual C++ Redistributable for VS 2015 was a part of the installation
3) Manually install the Visual C++ Redistributable for VS 2015 Update 3 mentioned in #7 – finally I got it working

I think this can discourage many of the potential LO users… :-(

(In reply to martin from comment #30)
> I tried to:
> 
> 2) Remove LO and Visual C++ Redistributable for VS 2015 and perform a fresh
> install – no success although I saw the Visual C++ Redistributable for VS
> 2015 was a part of the installation

... so you had the redistributable installed and listed in uninstall list? Absolutely unexpected.

What is your OS? (Please give details from winver launched using command line or Winkey+R).

What is the bitness of LibreOffice you used?

(In reply to Mike Kaganski from comment #31)
> ... so you had the redistributable installed and listed in uninstall list?
> Absolutely unexpected.

I mean - unexpected, that while the redistributable was on system, LibreOffice couldn't work.

(In reply to Mike Kaganski from comment #32)
> (In reply to Mike Kaganski from comment #31)
> > ... so you had the redistributable installed and listed in uninstall list?
> > Absolutely unexpected.
> 
> I mean - unexpected, that while the redistributable was on system,
> LibreOffice couldn't work.

I found a possible cause. Seems to be related to Service Pack 1 for Windows 7. I had not ever installed this service pack, and when I started manually getting the dlls that were listed as not being found, I found they were related to an update that will only work when SP1 is already installed.

I did a full wipe of my PC, and started fresh with W7SP1 installed. The redist package installs correctly from a download from MS, and then LibreOffice starts no problem.

Just an idea. Check to make sure SP1 is installed. Might fix your issue. Also might specify in the system reqs (if not already done) that SP1 is required for 6 to work with Windows 7.

(In reply to mistersketchman from comment #33)
> I found a possible cause. Seems to be related to Service Pack 1 for Windows
> 7. I had not ever installed this service pack, and when I started manually
> getting the dlls that were listed as not being found, I found they were
> related to an update that will only work when SP1 is already installed.

Maybe not. Mine has SP1 right from the start.

*** Bug 115769 has been marked as a duplicate of this bug. ***

(In reply to Kumāra from comment #34)
> (In reply to mistersketchman from comment #33)
> > I found a possible cause. Seems to be related to Service Pack 1 for Windows
> > 7. I had not ever installed this service pack, and when I started manually
> > getting the dlls that were listed as not being found, I found they were
> > related to an update that will only work when SP1 is already installed.
> 
> Maybe not. Mine has SP1 right from the start.

It wasn't SP1 that was required to run it. It was an update that needed SP1 to be installed. Right now I don't recall which update it was, but chasing down dlls pointed me to the update. I then tried to install the update, and Windows told me my version of Windows was not correct for the update. More searching showed that SP1 was required to install it.

So, it's not SP1 that was the issue. But if you had never installed it, you would also never get the update that had the dlls that were needed.

I have tried out the newest version of LibreOffice (LibreOffice_6.0.1_Win_x86.msi) and I also receive the same issue. I use Window 7 without SP1 and thus unable to install Visual C++ 2015 Redistributable Update 3 (as in Comment 7).

I have found a temporary solution for this issue 
(solution courtesy of Boris Silva R - Comment 26):

1. Install the Portable Version of LibreOffice.
2. Navigate through LibreOfficePortable\App\libreoffice\program and copy these dll files into LibreOffice Program File (LibreOffice\program)

A) all api-ms-win-*.dll. 
B) ucrtbase.dll

I wish that in the future installation pack it will include these dll files in the installation.

(In reply to Nickloh from comment #37)
> A) all api-ms-win-*.dll. 
> B) ucrtbase.dll
> 
> I wish that in the future installation pack it will include these dll files
> in the installation.

No, it will not. In 5.4, we had this temporary workaround (app-local redistributable), but as soon as we have found a way to avoid placing the libraries into the application directory, we have switched to that.

Having redistributable app-local means that this important third-party system component is not monitored and updated as required, e.g., when a security flaw in it is discovered. So - the release notes clearly indicate the minimum requirements to Windows OS that we support, which is Windows 7 SP1.

*** Bug 116077 has been marked as a duplicate of this bug. ***

I just encountered this issue for the first time after upgrading LibreOffice from 5.3.x to 6.0.2 on some old Win 7 computer.
I noticed that the installer tried to install some VC runtime, and even tough it apparently was successful I think (I didn't pay that much attention, sorry :/) I still had to install the Visual C++ 2015 Redistributable Update 3 mentioned in Comment #7 manually myself (then it worked)

I encounter the same error on windows 8.1 (ver 6.3.9600) X64

when i try to install "Visual C++ 2015 Redistributable Update 3"

I receive this error : 0x80240017

I've try with few other machine under Windows 8.1 same issue.

So I stick with LO 5.3.4 until a solution is released

(In reply to SpongeBob from comment #41)
> when i try to install "Visual C++ 2015 Redistributable Update 3"
> I receive this error : 0x80240017
> I've try with few other machine under Windows 8.1 same issue.
> 
> So I stick with LO 5.3.4 until a solution is released

https://support.microsoft.com/en-us/help/2906956

> To resolve this issue, install update rollup 2887595.
> 
> Microsoft has confirmed that this is a problem in the Microsoft products
> that are listed in the "Applies to" section.

(In reply to Mike Kaganski from comment #42)

I tried, but not working either...

The installation of the KB2887595 run smoothly (just to reboot once)

then when I install Libre office 6.0.2 I see that he install now the C++ 2015 Redistributable. 

But when I lunch LO he still give me the same error (api-ms-win-crt-runtime-l1-1-0.dll is missing)

I deinstalled the C++ 2015 Redistributable and tried to install the C++ 2015 Update 3 From Comment #7 but that one don't want to install himself Error (0x80240017)

Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=79383148bb31bee0c8fae941f6cc0fdd605fb2ea

tdf#108580 related: Check for SP level of the minimal supported OS

It will be available in 6.1.0.

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

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

(In reply to SpongeBob from comment #41)
> I encounter the same error on windows 8.1 (ver 6.3.9600) X64
> 
> when i try to install "Visual C++ 2015 Redistributable Update 3"
> 
> I receive this error : 0x80240017
> 
> I've try with few other machine under Windows 8.1 same issue.
> 
> So I stick with LO 5.3.4 until a solution is released

I was having the problem with Win7 al LO, upgrade my pc to sata and Windows 8.1 and get the same problem: the 2015 c++ runtime fail to run the x86 msu included in the  runtime.
The solution was update Windows 8.1 to the requisites of the 2015 c++ runtime( agust 201 rollup update?) then can install the c++ runtime and get working LibreOffice.
One alternative was download LibreOffice portable and copy the missing files to the main LibreOfiice

Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8faa1bc61fa8f09365d483364aea2b1c2751b587

tdf#108580 related: check for Windows 8.1 April 2014 update rollup

It will be available in 6.1.0.

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

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

Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1f8a3657216e44796cb94087450552aa977ebdae

tdf#108580 related: improve existing redist detection

It will be available in 6.1.0.

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

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

Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=158f6e5489d8167299deb53fde433e835019d10a&h=libreoffice-6-0

tdf#108580 related: Check for SP level of the minimal supported OS

It will be available in 6.0.4.

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

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

(In reply to Commit Notification from comment #48)
> Mike Kaganski committed a patch related to this issue.
> It has been pushed to "libreoffice-6-0":
> 
> Affected users are encouraged to test the fix and report feedback.

Hey I try the LibreOffice version : 
master64~2018-05-03_08.36.01_LibreOfficeDev_6.1.0.0.alpha1_Win_x64.msi

and indeed when I launch the install I get a message (~ please install KB2919355 ) That I try to do, but When I launch the setup of the KB2919355 for x64 I got : "The update is not applicable to your computer" So screw it I stay with an old version of L.B

(In reply to SpongeBob from comment #49)
> Hey I try the LibreOffice version : 
> master64~2018-05-03_08.36.01_LibreOfficeDev_6.1.0.0.alpha1_Win_x64.msi
> 
> and indeed when I launch the install I get a message (~ please install
> KB2919355 )

Great! So I see that the detection works correctly.

> That I try to do, but When I launch the setup of the KB2919355
> for x64 I got : "The update is not applicable to your computer" So screw it
> I stay with an old version of L.B

In this specific case I'd suspect some kind of corrupted system. It reminds me of bug 115405, where a system component was installed incorrectly by some other application. https://ask.libreoffice.org/en/question/152440 gives another example of a third-party script breaking system, which happened to surface when using LibreOffice.

This kind of problem requires individual investigation and fixing on system level, but is outside of this bug 108580.

(In reply to SpongeBob from comment #49)
> Hey I try the LibreOffice version : 
> master64~2018-05-03_08.36.01_LibreOfficeDev_6.1.0.0.alpha1_Win_x64.msi
> 
> and indeed when I launch the install I get a message (~ please install
> KB2919355 ) That I try to do, but When I launch the setup of the KB2919355
> for x64 I got : "The update is not applicable to your computer" So screw it
> I stay with an old version of L.B

Does it say WHY "The update is not applicable to your computer"? Just acting on a possible cause: Is your OS 32-/64-bit?

(In reply to Kumāra from comment #51)
> (In reply to SpongeBob from comment #49)
> > Hey I try the LibreOffice version : 
> > master64~2018-05-03_08.36.01_LibreOfficeDev_6.1.0.0.alpha1_Win_x64.msi
> > 
> > and indeed when I launch the install I get a message (~ please install
> > KB2919355 ) That I try to do, but When I launch the setup of the KB2919355
> > for x64 I got : "The update is not applicable to your computer" So screw it
> > I stay with an old version of L.B
> 
> Does it say WHY "The update is not applicable to your computer"? Just acting
> on a possible cause: Is your OS 32-/64-bit?

Of course... not :/ My Os is 64Bit and the update also..

(In reply to Mike Kaganski from comment #50)
> (In reply to SpongeBob from comment #49)
> > Hey I try the LibreOffice version : 
> > master64~2018-05-03_08.36.01_LibreOfficeDev_6.1.0.0.alpha1_Win_x64.msi
> > 
> > and indeed when I launch the install I get a message (~ please install
> > KB2919355 )
> 
> Great! So I see that the detection works correctly.

OK, but is this all that can be done for this issue? I was hoping I could just install LO and be done with it.

Anyway, I'm hoping to save some time for me. Other than SpongeBob, has anyone else tried? What's your experience?

(In reply to Kumāra from comment #53)
> OK, but is this all that can be done for this issue? I was hoping I could
> just install LO and be done with it.

Which specific issue do you refer to as "this"?

Currently, the installer for Windows must:
1. Properly detect all OSes that LO *cannot* be installed to - on these OSes, you are *not* expected to "just install" this version of LO, and properly informing and exiting is all that *should be* done;
2. Properly install the redist on the OSes where it *is* applicable.

In the next version (6.1), the installer will also install the required components without additional interaction (no additional authentication/authorization), much like before 6.0 (though the inner machinery is different), to improve installation experience.

A broken OS is a special case for any software. An OS without a required component (as in SpongeBob's case) is unsupported (1) case. Inability to install any component on an OS is *not* a problem LibreOffice installer should deal with.

(In reply to Mike Kaganski from comment #54)
> (In reply to Kumāra from comment #53)
> > OK, but is this all that can be done for this issue? I was hoping I could
> > just install LO and be done with it.
> 
> Which specific issue do you refer to as "this"?

This bug, this "Cannot run LibreOffice" because "api-ms-win-crt-runtime-l1-1-0.dll is missing". Anyway, I now get that you're saying it's completely not in the domain of LO, which can at best only get Windows to download the needed components.

I just found this which affected ones might be interested to try:
http://www.thewindowsclub.com/api-ms-win-crt-runtime-l1-1-0-dll-is-missing

> In the next version (6.1), the installer will also install the required
> components without additional interaction (no additional
> authentication/authorization), much like before 6.0 (though the inner
> machinery is different), to improve installation experience.

This sounds good.


> A broken OS is a special case for any software. An OS without a required
> component (as in SpongeBob's case) is unsupported (1) case. Inability to
> install any component on an OS is *not* a problem LibreOffice installer
> should deal with.

I get that. Now still waiting for responds from others here who might have tried the latest.

Wonder if this is relevant here:

The file api-ms-win-crt-runtime-l1-1-0.dll exists in my computer, many times over, for Mozilla Firefox, Avast and Calibre, besides 2 instances under Windows.

As suggested by the webpage I showed above, I've tried to re-register the file with regsvr32. For both instances, I got this error message:

The module "api-ms-win-crt-runtime-l1-1-0.dll" was loaded but the entry-point DllRegisterServer was not found.

Make sure that "api-ms-win-crt-runtime-l1-1-0.dll" is a valid DLL or OCX file and then try again.

Come to think of it, it's just a 23kb file. If Mozilla Firefox, Avast and Calibre can include it as part of the package, perhaps LO can too. This is assuming the issue lies with this file only.

(In reply to Kumāra from comment #56)
> Come to think of it, it's just a 23kb file. If Mozilla Firefox, Avast and
> Calibre can include it as part of the package, perhaps LO can too. This is
> assuming the issue lies with this file only.

Erm... Probably not. I see under Avast, it's part of 2 folders of seemingly relevant stuff, about 5MB. (I think  one is for 32bit and the other for 64bit.)

I'd still prefer that LO could make use of what's already in Windows, instead of installing extra baggage. I'll try to solve it myself. However, less tech-savvy ones would probably just give up. So, again, perhaps LO might just consider just include it in the package. OR maybe what you mentioned for 6.1 is something niftier.

(In reply to Kumāra from comment #57)

LibreOffice installer for 6.0 (and 6.1, in a different form) *does* include the files. In 6.0, it's the whole VC redist installer from comment 7, ~14 MB, that is launched at the end of installation. The difference from all of (LO 5.4, FireFox, Avast) is that 6.0+ does not put the files in LO's own directory, but installs the component properly using its own installer. It is done not to save space, but to ensure that system components (and ucrt *is* a system component) are getting updates from the component's vendor. Otherwise, e.g. a security treat may arise from a user unknowingly using unpatched version of ucrt in LO, while the user might be sure that OS is fully updated (and not know that some sw bundles older vulnerable copies of OS components).

(In reply to Mike Kaganski from comment #58)

Thanks for taking the effort to explain. I'm much clearer of the picture.

Meaning, by right, it should work unless something is wrong with the user's system.

I was misled by your exchange with SpongeBob that the fix was merely to detect the lack of components the new LO depend on.

Anyway, I'll give LO6.0.4 a shot and report back.

A bit too long explanation of the problem's timeline to this already a bit too long thread; writing this here to be able to refer to when clarifications needed in the future.

After LibreOffice 5.3 was branched off, in the early 2017, the development branch toward 5.4 had switched to Visual Studio 2015 as baseline compiler for Windows [1]. This was needed to switch to the next CRT and C++ standard support (which in turn allows to write more efficient and less error-prone code, and thus, improve development for a huge codebase that LibreOffice is), and the switches to the new C Runtime library have happened before each time we upgraded compiler requirements; previously, these switches did not give much headaches, because we have always bundled the C Runtime redistributable in form of merge modules provided by Visual Studio itself [2].

This time, however, it turned out that we had overlooked that Microsoft had changed the redistributable and its installation since 2015 version. Now the redistributable consists of two independent parts (VCRT and UCRT), and the latter is the system component (included in the base installation of Windows 10, but required to be installed separately to Windows XP to 8.1). And what's important, MS own redist merge module used in LO installer *does* include the UCRT bits as well as VCRT, but it only installs the former to Windows XP, while for Windows Vista+, it does not do that (for purpose - see comment by James McNellis from 2016-03-11 at [3]).

So, having missed that at the 5.4 testing phase somehow (possibly because those who tested on Win 7-8.1 all had VCRedist 2015 installed separately), users started to complain about this bug when installing onto Windows 7 through 8.1 *without* VCRedist 2015. Those using Windows XP or Windows 10 were unaffected.

To solve the problem, we had implemented the App-local deployment of the Universal CRT (see #6 at the bottom of the article [3]) since version 5.4.3 [4] - see comment 21 and the two below for commit notifications. This meant that we put the required UCRT libraries into the LibreOffice installation directory, and thus not rely upon system UCRT. As mentioned, while this works, this is not a recommended option, and may create security concerns. So, at the time of those commits, Christian already mentioned that it's a workaround, not the proper solution.

So, we kept working to find a way to use the correct MS-advised UCRT install method in LibreOffice installer, and for 6.0, we included [5] the installer from Microsoft [6] (see comment 7) into the MSI so that it was launched at the end of installation process, asked to authorise second time, and then did whatever it was needed to install both VCRT and UCRT. So, we were pretty sure that now everything should work as it should, because the MS installer would of course do it properly.

And of course, it didn't. It turned out that it worked only partially on those systems that didn't match the minimal requirements for the UCRT [7] - those are April 2014 rollup for Windows 8.1, Service Pack 1 for Windows 7, and Service Pack 2 for Windows Vista (the latter being irrelevant for LO 6.0+). The MS installer only installed VCRT component, and reported success, while UCRT remained missing on the system. And at the 6.0, we started to receive the new wave of the same error reports from users attempted to install LibreOffice on those systems not matching the UCRT (and LO [8]) minimal requirements.

So the next part of the solution was to fix out installer to properly detect those OS versions, and prevent LO from installing there (because, naturally, the vital UCRT system component would be missing there, and LO wouldn't run anyway), issuing proper message. That was done in the commits notified by comment 38, comment 44, comment 46 and below. Since then, the only remaining issue (which cannot be solved on the LibreOffice installer side) is when user's system is broken in a way, so that it either cannot install UCRT (being eligible for it), or reports that it's already installed, but actually it's not. The broken OS (which might be caused by e.g. third-party software playing dirty tricks with ucrt - see bug 115405 for example) is outside of the scope of this bug.

And last (at the time of writing this) is the commits that have changed the UCRT installation procedure for 6.1 [9]: we now don't bundle the EXE from comment 7, but instead, UCRT packages from [10], which are installed (using proper MS tooling [11] for Windows Updates) in the course of main installation process, instead of launching separate second installation after LO installation has finished. This allows us to avoid the second authorization step, making installation experience more smooth; and also allows to install UCRT in unattended scenarios (which were unsupported in 6.0, and required separate UCRT installation by those who use unattended LO installations, like corporate deployments). As with 6.0, this still checks the pre-requisite OS level, and refuses to install when it doesn't fit the minimal requirements; and of course, this won't work in cases of broken OSes.

That's all the story thus far; the unfortunate decision of Microsoft to split the redistributable had brought a lot of trouble, of course; but hopefully, we now do it The Right Way (TM).

[1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=84b36c704d73362d4d86dc9e9c0efa0625958347
[2] https://msdn.microsoft.com/en-us/library/ms235290
[3] https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
[4] http://cgit.freedesktop.org/libreoffice/core/commit/?id=71d9a61302e65fe091cf70c13fa72b3df09b7e3a
[5] http://cgit.freedesktop.org/libreoffice/core/commit/?id=61b1d631331551b43bc7d619be33bfbfeff7cad6
[6] https://www.microsoft.com/en-us/download/details.aspx?id=53840
[7] https://support.microsoft.com/en-us/help/2999226
[8] https://www.libreoffice.org/get-help/system-requirements/#windows
[9] https://cgit.freedesktop.org/libreoffice/core/commit/?id=b84244378d411b83355b8763d3505031dd5ec324
[10] https://www.microsoft.com/en-us/download/details.aspx?id=48234
[11] https://support.microsoft.com/en-us/help/934307

I've just installed LO6.0.4. Hmmmmm... Same old "api-ms-win-crt-runtime-l1-1-0.dll is missing".

Then, I took one of the suggestions from the webpage I suggested earlier (http://www.thewindowsclub.com/api-ms-win-crt-runtime-l1-1-0-dll-is-missing): 

Update for Universal C Runtime
Download the Update for Universal C Runtime from Microsoft (https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows). Install the Runtime component and restart your computer and see. Just for your information, starting with Windows 10, the Universal CRT is part of the operating system.

Then, I started LO. No error message. OK... So far so good. And I waited, and waited, monitoring WTM. I saw soffice.bin there, but it seemed stuck. And I waited, and waited.

Suddenly the LO "splash banner" came out. Alright... And I waited, and waited, and... yes! LO is up and running!

But gee... that took a very long time. I guess some kind of run-once initiation was necessary, or it's just my computer. Anyway, to be sure, I unloaded and reloaded LO, and startup was fast, even without the quick-starter.

Great.

But now for some strange reason, the fonts provided with LO (DejaVu, Liberation, etc) all appear like Courier New. I can't even use them on other programs. I suppose restarting the computer would solve this.

Last mentioned issue with fonts is likely Bug 97982.

*** Bug 118869 has been marked as a duplicate of this bug. ***

*** Bug 119910 has been marked as a duplicate of this bug. ***

*** Bug 123229 has been marked as a duplicate of this bug. ***

Kumāra: since you had to install crt things, I'd do the famous steps to be sure everything is clean with LO part:
- uninstall
- clean registry (with ccleaner or any tool you trust)
- remove any remnant Lo files you got
- remove LO profile (see https://wiki.documentfoundation.org/UserProfile#Windows) 
- install LO again (6.2.4) from official website

(check if you choose LO 64 bits, you should have Java 64 bits, 
...LO 32 bits -> Java 32 bits)

Changing priority to 'high' since the number of duplicates is 5 or higher

So I suppose that all the changes to installer I made to correctly install UCRT, and handle all the oddities resulting from MS making it so ridiculously hard, fixed this. No reports in current versions. Closing FIXED. Any newer problems, even looking similar, need own reports, possibly with this one in See Also.