Bug 69066 - Upgrading LO requires user to terminate Explorer.exe on Windows because of LO Explorer/Shell extensions (Workaround: comment 12)
Summary: Upgrading LO requires user to terminate Explorer.exe on Windows because of LO...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
4.1.1.2 release
Hardware: All Windows (All)
: high normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:5.3.0
Keywords: notBibisectable, regression
: 71163 78057 93158 95435 104585 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-09-07 10:15 UTC by Luuk
Modified: 2024-05-20 09:47 UTC (History)
14 users (show)

See Also:
Crash report or crash signature:


Attachments
Installation assistent (27.73 KB, image/png)
2013-09-07 10:15 UTC, Luuk
Details
installation wizard error dialog (33.29 KB, image/jpeg)
2014-01-05 02:31 UTC, RobK
Details
New RestartManager installation dialog (14.63 KB, image/png)
2016-08-16 20:49 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Luuk 2013-09-07 10:15:36 UTC
Created attachment 85393 [details]
Installation assistent

When upgrading 4.1.0 to 4.1.1.2 i got a notice about a process that was using files and needed to be closed before installing could continue.
See attached screendumps (unfortunatly some are in Dutch

This process is not an application that i can 'normally' close. So, i do think that i should not get this notice

Installation should continue, and a messag (probably about a reboot that is required should follow)   ;(

The information on process 7740 is:
C:\Users\Luuk>tasklist /V /FI "PID eq 7740" /FO csv
"Image Name","PID","Session Name","Session#","Mem Usage","Status","CPU Time","Window Title"
"explorer.exe","7740","Console","1","95.264 K","Running","0:00:13",".NET-BroadcastEventWindow.2.0.0.0.2e0c681.0"
Comment 1 Maxim Monastirsky 2013-11-02 16:54:02 UTC
*** Bug 71163 has been marked as a duplicate of this bug. ***
Comment 2 Kumāra 2013-11-05 06:52:15 UTC
I include here the bug report from Bug 71163, which I think is clearer:

Chris  2013-11-02 14:24:55 UTC 
When I installed the new version of LibreOffice on my Windows 8.1 desktop, it will pop up during the validating install process stating that you have to close explorer.exe to continue. If you tell it to ignore it, it will not proceed until you close it. I had to go to task manager and kill explorer.exe to finish installing. Then, you have to re-launch explorer.exe to be able to use anything in windows 8.1 .

I encountered the same in a recent upgrade with LibO 4.1.2.3 on Windows Home Premium 64bit.

I'm marking importance as high as this stumps novices, and gives LO a bad reputation.
Comment 3 Maxim Monastirsky 2013-11-08 08:24:35 UTC
Might be related to Bug 56007.
Comment 4 Michael Stahl (allotropia) 2013-12-02 19:04:02 UTC
Andras, any idea why this happens?

does it happen only on Windows 8.1 or older versions too?
Comment 5 Kumāra 2013-12-03 02:22:42 UTC
Happens to me on Windows 7 HP 64-bit.
Comment 6 Andras Timar 2013-12-03 10:00:36 UTC
(In reply to comment #4)
> Andras, any idea why this happens?

Unfortunately I couldn't reproduce it. It can be related to shell extensions or indexing service. For example the shell extension is generating a thumbnail of a file which is on a slow drive (reading 1 byte at a time, see bug 56007), therefore Explorer holds that dll during uninstall. Hopefully the bug will not be reproducible with 4.1.4. On the other hand, if user ignores this warning, the uninstaller will ask for a reboot in order to complete uninstall process.
Comment 7 RobK 2014-01-05 02:31:07 UTC
Created attachment 91506 [details]
installation wizard error dialog
Comment 8 RobK 2014-01-05 02:31:47 UTC
I also am having the problem same as described in by Luuk below. Error dialog is also the same (in English though).
I am trying to update from 4.1.3.2 to 4.1.4.2.
My system is Windows 64 HP AMD 64-bit.

While there is a work-around, I really do like to monkey with installations in case there is some secondary effect.
I also give this high importance, as I have not see such a terminal error in other software installation.

I am willing to wait until next version, hopefully this can be fixed.
Comment 9 RobK 2014-01-05 02:35:48 UTC
Sorry, I meant I really don't like to monkey with installations.
Comment 10 RobK 2014-01-05 02:48:04 UTC
Sorry, I also meant Windows 7 HP, AMD 64-bit.
Comment 11 Kumāra 2014-01-06 02:28:46 UTC
(In reply to comment #8)
> I also am having the problem same as described in by Luuk below. Error
> dialog is also the same (in English though).
> I am trying to update from 4.1.3.2 to 4.1.4.2.
> My system is Windows 64 HP AMD 64-bit.

Thank you for reporting. However, please do not "update" the version number. It's suppose to show the earliest version the issue is occurring. I'm changing it back to the original.

The matter seems to be inconstant. When I upgraded to 4.1.4.2, the matter didn't arise at all. The difference I notice is that Explorer is set not to show thumbnails. So, Andras's guess is probably correct.

I wouldn't want to label this "notourbug" though, since the issue don't occur with installations of (most) other programs.

Meanwhile, I encourage affected ones to test. In Windows Explorer, go to Organize > Folder and search options > View tab. Tick "Always show icons, never thumbnails". Then install LO.
Comment 12 RobK 2014-01-09 23:19:16 UTC
I tried the suggestion by Kumara in Comment 11.

"In Windows Explorer, go to Organize > Folder and search options > View tab. Tick "Always show icons, never thumbnails". Then install LO."

Then I was able to install LO without any problems, and applications so far appear to work properly.

So I can recommend this as a possible workaround.

Thanks Kumara.
Comment 13 Michael Stahl (allotropia) 2014-02-03 17:09:55 UTC
given that bug 56007 is fixed and the shell extensions should
be much faster, can anybody still reproduce this problem when
upgrading _from_ LO 4.1.4.2 (or later) to a later version?
Comment 14 Michael Meeks 2014-02-11 13:29:09 UTC
as per mst's question ...
Comment 15 Luuk 2014-02-14 16:57:01 UTC
(In reply to comment #14)
> as per mst's question ...

/me did not have the bug again (as far as i remember), and i'm currently running 4.2.0.5 on Windows 7

I'm asking others, who can reproduce this, to give info.
But i doubt anyone having this problem will be saving enough info in order to post it here when they found this bug.....
Comment 16 Sander Voerman 2014-02-15 17:43:17 UTC
I just experienced the same problem, trying to install the 32bits x86 version of LibreOffice (4.2.0.4) on a 32 bits Windows 7 system.
Comment 17 Sander Voerman 2014-02-15 18:29:09 UTC
(In reply to comment #11)
> Meanwhile, I encourage affected ones to test. In Windows Explorer, go to
> Organize > Folder and search options > View tab. Tick "Always show icons,
> never thumbnails". Then install LO.

This workaround did not help on my system.

(In reply to comment #2)
> I had to go to task manager and kill
> explorer.exe to finish installing. Then, you have to re-launch explorer.exe
> to be able to use anything in windows 8.1 .
> 

This did work on my system (32bits windows 7, Intel Pentium Dual Core E5300). When the installer finished, I logged out of windows using task manager and then logged back in to restart explorer and get my desktop back.
Comment 18 RobK 2014-02-15 19:36:24 UTC
I updated from 4.1.4.2 to 4.2.0.4 and the installation worked correctly. In my case the issue seems to be solved.
Again this is on Win7 64-bit AMD.
Comment 19 Michael Stahl (allotropia) 2014-02-16 21:20:31 UTC
(In reply to comment #16)
> I just experienced the same problem, trying to install the 32bits x86
> version of LibreOffice (4.2.0.4) on a 32 bits Windows 7 system.

which was the installed LO version _before_ the upgrade?
Comment 20 Sander Voerman 2014-02-17 08:23:44 UTC
(In reply to comment #19)
> which was the installed LO version _before_ the upgrade?

None; in my case it was not an upgrade, but rather a fresh install.
Comment 21 Kumāra 2014-02-17 10:48:31 UTC
(In reply to comment #20)
> (In reply to comment #19)
> > which was the installed LO version _before_ the upgrade?
> 
> None; in my case it was not an upgrade, but rather a fresh install.

Hmmm... Shall we mark this as major?
Comment 22 Michael Stahl (allotropia) 2014-02-17 11:40:00 UTC
(In reply to comment #21)
> (In reply to comment #20)

> > None; in my case it was not an upgrade, but rather a fresh install.
> 
> Hmmm... Shall we mark this as major?

that is the _first_ report of somebody claiming to have this problem
on a fresh installation with no older LO installed on the system;
since this bug is about upgrades it's probably a different bug
which would be UNCONFIRMED, not NEW as this one.
Comment 23 Kumāra 2014-02-18 03:59:20 UTC
(In reply to comment #22)
> that is the _first_ report of somebody claiming to have this problem
> on a fresh installation with no older LO installed on the system;
> since this bug is about upgrades it's probably a different bug
> which would be UNCONFIRMED, not NEW as this one.

Please forgive if I'm making a wrong assumption here. It seems to me that it's not a separate bug. The issue is not between the installer program and the installed LO, but between the installer program and Explorer.exe. So, it should make no difference between an upgrade and a fresh install.
Comment 24 Kumāra 2014-02-18 04:13:03 UTC
I've just upgraded to 4.2.0.4 with Explorer's thumbnails on. No hitches. So, it seems the goal post has moved.
Comment 25 Michael Stahl (allotropia) 2014-02-19 14:51:23 UTC
(In reply to comment #23)
> (In reply to comment #22)
> > that is the _first_ report of somebody claiming to have this problem
> > on a fresh installation with no older LO installed on the system;
> > since this bug is about upgrades it's probably a different bug
> > which would be UNCONFIRMED, not NEW as this one.
> 
> Please forgive if I'm making a wrong assumption here. It seems to me that
> it's not a separate bug. The issue is not between the installer program and
> the installed LO, but between the installer program and Explorer.exe. So, it
> should make no difference between an upgrade and a fresh install.

No, _this_ bug is about LO bundled Explorer extensions to view thumbnails
of various documents, which somehow prevents installation of
new LO versions presumably because these Explorer extension files cannot
be overwritten or deleted; naturally on a "fresh" install you won't
have LO Explorer extensions running.

(actually i cannot imagine how there could be a conflict between
Explorer.exe and LO installation without a LO previously installed
on the system, but this is Windows and it's full of mysteries
so what do i know anyway...)
Comment 26 Sander Voerman 2014-02-19 15:13:43 UTC
(In reply to comment #25)
> (actually i cannot imagine how there could be a conflict between
> Explorer.exe and LO installation without a LO previously installed
> on the system, but this is Windows and it's full of mysteries
> so what do i know anyway...)

Just speculating: I did have MS Office 2013 installed, which also has bindings for open document filetypes. In addition to explorer.exe, the LO installer sometimes also mentioned a Microsoft Office document cache process as one of the things it needed to be terminated before proceeding with the installation. So perhaps Microsoft Office causes a similar connection between explorer and the open document filetypes, and thereby a similar conflict for the LO installer.
Comment 27 Cor Nouws 2014-05-25 20:21:02 UTC
*** Bug 78057 has been marked as a duplicate of this bug. ***
Comment 28 Michael Bauer 2014-07-01 12:34:46 UTC
Also seem to be having this problem going from 4.2.4.2 to 4.2.5.2. It brings up the error message that files used by this setup need to be closed, Windows Explorer Process ID 5484. Googling that landed me on this questions page http://ask.libreoffice.org/en/question/27733/libreoffice-4142-install-error-files-in-use/ and some further googling to this bug report.

I have not tried any of the fixes just in case I can help with identifying the problem but I am, at this stage, wondering if it's related to this issue http://ask.libreoffice.org/en/question/16047/error-1303-when-installing-libreoffice-402-on-windows-8-pro/#30099 which made me install LO in a folder outside the default /Programs folders.

I'm on Win 8 (with a Gaelic langpack), 64bit, with Office 2013 also installed.
Comment 29 Michael Bauer 2014-07-07 21:28:00 UTC
Dunno if it helps but I just had an odd solution to this problem. I needed to check something in the localization of OO that I also maintain and remembering the issues with having both installed, I uninstalled LO completely before re-installing LO.
Now before I installed OO I tried to delete the LO folder under C:/Programs and it would not let me with no specific error message. I then installed OO and had to restart. After re-starting, I could delete the LO folder.
Funnily enough I ran into the *same* problem trying to delete the OO folder under C:/Programs before re-start - but again fine AFTER restart.
Seems to me like there's some LO process that just keeps on running even after de-installation that interferers with deleting (in my case) or (in the update case) over-writing. At least that's my guess.
Comment 30 Michael Bauer 2014-07-08 16:06:38 UTC
The saga continues. There is something ... cavalier about the shoddy install process. So after my last report of being able to install it correctly has to get amended. It installs and fires up and I can open documents from the Recents list but har-dee-har-dee-har, if I use a link on my desktop to open an .odr file or if I browse to it using Explorer, I get this error:
"Another program is currently using this file"

So I then uninstall LO and re-install it (a chore in itself, the installer is still mental, how about someone sorting the UI languages *alphabetically*???) on my second hard drive in a non-system created folder E:/Programs/ and suddenly everything works again.

Seems to me LO does *NOT* like being in the default system folders for programs.
Comment 31 Kumāra 2014-07-09 03:10:01 UTC
Michael Bauer, thanks for your reports. However, Comment 29 and 30 don't seem to be related to this bug. Please report them elsewhere.

I've changed platform too All Windows based on comment 16, and added a comment on whiteboard to a workaround.
Comment 32 Michael Bauer 2014-07-09 10:13:27 UTC
I'm not a developer but my gut tells me they ARE related, it's the same chain of installation events the way I see it.
Comment 33 Kumāra 2015-02-15 00:28:46 UTC
I've not seen this bug for a while. In my last installation, I'm certain that I had thumbnails on. Anyone faced this bug in recent versions?
Comment 34 Michael Bauer 2015-02-15 13:58:21 UTC
I've not had it for a few versions either. Perhaps close it for now?
Comment 35 Luuk 2015-02-15 14:30:52 UTC
It might be wise to add some info to this bug.

Info that shows how to gather some info is needed to solve this bug when someone has this situation again (in a later version)

Simply closing because this bug is open for 1 year and 5 month without any progress is a bit odd for developers who want to make a good product.

I mean: 'Sorry we cannot reproduce the bug', ...... well lets wait a couple of months, and than put it in a status where no one will ever find it..... ?

(I'm aware of the fact that I did not put much info in my bug report, but I don't know how to get more info when this sort of thing happens....)
Comment 36 Robinson Tryon (qubit) 2015-02-15 20:15:35 UTC
(In reply to Luuk from comment #35)
> It might be wise to add some info to this bug.
> 

Definitely!

> Simply closing because this bug is open for 1 year and 5 month without any
> progress is a bit odd for developers who want to make a good product.

But that's not what people are saying...

(In reply to Kumāra from comment #33)
> I've not seen this bug for a while. In my last installation, I'm certain
> that I had thumbnails on. Anyone faced this bug in recent versions?

(In reply to Michael Bauer from comment #34)
> I've not had it for a few versions either. Perhaps close it for now?

The reason why we spend time on bug reports is so that developers can identify and fix bugs in LibreOffice. If we can't reproduce the problem in a modern version of LibreOffice or on a modern operating system, then a bug report is just a historical record.

> 
> (I'm aware of the fact that I did not put much info in my bug report, but I
> don't know how to get more info when this sort of thing happens....)

It looks like the last confirmation of this report was a year ago to the day, and in fact the devs are suspicious that said report (comment 16) is even talking about the same bug.

It would be great if someone could try to reproduce this problem using a 4.4 or 4.5 build. If we can't reproduce it there, then I think it's most useful for the development workflow for us to mark it as 'RESOLVED WORKSFORME' until someone has the same bug show back up again.
Comment 37 raal 2015-02-15 22:22:12 UTC
(In reply to Robinson Tryon (qubit) from comment #36)
> 
> It would be great if someone could try to reproduce this problem using a 4.4
> or 4.5 build. If we can't reproduce it there, then I think it's most useful
> for the development workflow for us to mark it as 'RESOLVED WORKSFORME'
> until someone has the same bug show back up again.

Hi Robinson,
I upgraded from 4.3 to 4.4.0.3 without problem. Instalation of daily builds 4.5 I'm doing few times in a month and didn't noticed any problem. windows7.
Comment 38 Kumāra 2015-02-16 03:16:40 UTC
(In reply to Luuk from comment #35)
> (I'm aware of the fact that I did not put much info in my bug report, but I
> don't know how to get more info when this sort of thing happens....)

Have you encountered the same bug in recent versions?
Comment 39 sweettooth 2015-05-24 20:41:22 UTC
Did encounter this today when tried to upgrade on a win 7 pro 64

Have 4.2.8.2 and was trying to install 4.3.6
Comment 40 Andras Timar 2015-07-07 12:19:45 UTC
According to collective wisdom of people on internet, it is not possible to unload a shell extension dll during uninstall. If the file is in use, then restart is needed.
Comment 41 Buovjaga 2015-11-09 10:02:38 UTC
*** Bug 95435 has been marked as a duplicate of this bug. ***
Comment 42 Kumāra 2015-11-11 06:57:06 UTC
(In reply to Beluga from comment #41)
> *** Bug 95435 has been marked as a duplicate of this bug. ***

So looks like the problem remains. So, I'm reopening it.
Comment 43 Adolfo Jayme Barrientos 2015-11-15 00:50:07 UTC
Closing per comment 40. Do not reopen again. Marking another bug as a duplicate does not automatically accounts to changing the other bug’s resolution.
Comment 44 Adolfo Jayme Barrientos 2015-11-15 00:51:04 UTC
*** Bug 93158 has been marked as a duplicate of this bug. ***
Comment 45 Michael Bauer 2015-11-15 02:20:58 UTC
I don't doubt the collective wisdom of the internet but restarting the system does not fix the issue. I have tried restarting the system umpteen times when I get a LO release with this problem.
Comment 46 Kumāra 2015-11-16 09:12:17 UTC
(In reply to Adolfo Jayme from comment #43)
> Closing per comment 40. Do not reopen again. Marking another bug as a
> duplicate does not automatically accounts to changing the other bug’s
> resolution.

True, but the bug remains, and I can imagine any less-than-tech-savvy user to be put off by it.

If this is impossible to fix technically, at the very least, give the user the heads-up in the Windows installation dialog.

I'm not sure which is better:
1. Terminate Explorer, Continue with LO installation, Restart Explorer
2. As I suggested in Comment 11.
Comment 47 Michael Bauer 2015-11-16 09:52:43 UTC
There is a third option. Create a directory OUTSIDE ../Programs or ../Programs (x86) (whatever the Windows default is the system in question. For some odd reason, that workaround always works.

We could add a message saying "Windows is preventing LO from installing to this directory. Would you like us to create c:\LO (or whatever) and continue with the installation?"
Comment 48 Robinson Tryon (qubit) 2015-12-17 10:55:14 UTC Comment hidden (obsolete)
Comment 49 Michael Bauer 2016-05-12 23:04:26 UTC
Just tried to install 5.1.2 and got this one again.

I'm re-opening the bug in spite of what Adolfo said. With all due respect, it is *crazy* to leave a bug unresolved (however ugly the solution might be). It's a bug that prevents installation of the product to a not insignificant number of people. If that's not shooting ourselves in the foot, the I don't know what is.

At the *very* least the error message needs modified to give the user a clue as to what's going on and how to work around it.
Comment 50 V Stuart Foote 2016-07-30 14:01:12 UTC
Can not reproduce.

On Windows 10 Pro 64-bit en-US with
Version: 5.2.0.3 (x64)
Build ID: 7dbd85f5a18cfeaf6801c594fc43a5edadc2df0c
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
Locale: en-US (en_US)

Upgraded install to
Version: 5.2.0.4 (x64)
Build ID: 066b007f5ebcc236395c7d282ba488bca6720265
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; 
Locale: en-US (en_US)

1. Windows Explorer open and view mode set to Large Icons
2. Windows Explorer Options -> Change folder and Search options -> Folder Options dialog -> View tab "alwasy show icons, never thumbnails" set *unchecked* -- ODF thumbnails are displayed.
3. opened Command Prompt (Admin) so "Run as Administrator"
4. CLI upgrade with verbose logging  "msiexec.exe /i LibreOffice_5.2.0.4_Win_x64.msi /L*v upgradeInstall5204.log"
5. during the upgrade use Windows Explorer and change between folders with ODF documents. Documents continue to show thumbnails--but briefly show only ODF icons--then back to thumbnails.
6. upgrade runs to completion

Review of the log reveals nothing had blocked for any of the "shlxthdl" DLLs: ooofilt.dll, shlxthdl.dll, propertyhdl.dll

The ops to remove and then install and then register all seem normal.
Comment 51 Mike Kaganski 2016-08-16 09:28:55 UTC
Came across this after a mention in IRC.

I've some substantial experience as a system administrator in an company that uses Windows desktops. I had countless installs/upgrades/uninstalls of MSIs and non-MSI installer.

And I must say that there is only **one** comment here that marks some possible problem. That's comment 2, that says that

> If you tell it to ignore it, it will not proceed until you close it.
> I had to go to task manager and kill explorer.exe to finish installing

That's really strange.
Otherwise, the MSI-based installer telling you that Explorer.exe is using a resource, and should be closed to avoid restart, is perfectly OK. MSI technology in made to do that. And it's OK for explorer.exe to use LO shell extension DLL - and there's no way to unload it other than close explorer.exe.

Normal sequence is this:
installer detects a busy resource; it tries to find a process that holds it busy; (some installers also look for windows with some pre-defined strings, thus firing false positives); if it finds one, it asks to close it, and warns that otherwise a reboot required. If user agrees to close it, the process closes and install continues normally, replacing the previously-busy DLL.
If user disagrees, then the new DLL is copied to a temporary place to be replaced at reboot; and after the installation finishes, it asks for reboot.

The problems that are discussed here must be as follows: (1) if the installer is UNABLE to continue without closing explorer.exe; and (2) if it is UNABLE to close explorer.exe when told so.

If these two cases do happen, then they should really must be debugged and fixed. Otherwise, if the described normal behaviour takes place, then it is not anyone's bug.
Comment 52 Sander Voerman 2016-08-16 10:37:42 UTC
(In reply to Mike Kaganski from comment #51)

> Normal sequence is this:
> installer detects a busy resource; it tries to find a process that holds it
> busy; (some installers also look for windows with some pre-defined strings,
> thus firing false positives); if it finds one, it asks to close it, and
> warns that otherwise a reboot required. If user agrees to close it, the
> process closes and install continues normally, replacing the previously-busy
> DLL.
> If user disagrees, then the new DLL is copied to a temporary place to be
> replaced at reboot; and after the installation finishes, it asks for reboot.

I agree, except that many other installers attempt to restart explorer.exe at the end of the installation process. For example, the installers of cloud/encryption services like SpiderOak or BoxCryptor, which also need to close explorer during installation, do exactly that. If there are still scenarios in which the current LibreOffice version's installer needs to close explorer.exe, than that would be a welcome functionality for non-tech savvy users, as many of them do not know how to start explorer.exe manually when their task bar and start menu have disappeared.
Comment 53 Mike Kaganski 2016-08-16 10:53:52 UTC
MSIRESTARTMANAGERCONTROL
https://msdn.microsoft.com/en-us/library/windows/desktop/aa370377
Comment 54 Mike Kaganski 2016-08-16 12:01:12 UTC
Taking
Comment 55 Mike Kaganski 2016-08-16 14:03:42 UTC
Summary:
The goal is to allow installer to automatically close and restart closed applications, and thus diminish users frustration when they don't know how to close explorer.exe, or how to start it again and bring desktop back.

Reference: https://msdn.microsoft.com/en-us/library/windows/desktop/aa370379

Notes:
* The feature is called Restart Manager.
* A dialog MsiRMFilesInUse must be present in MSI.
* It will only be used when operating system's Windows Installer version is >=4.0, and OS is Vista or newer. If system's Windows Installer is older, then current FilesInUse dialog will be used.
* MSIRESTARTMANAGERCONTROL property, that is not defined in LO MSI, has default value of 0, that enables installer to use the restart manager.

A patch is submitted to gerrit for review: https://gerrit.libreoffice.org/28171
Comment 56 Mike Kaganski 2016-08-16 20:49:35 UTC
Created attachment 126859 [details]
New RestartManager installation dialog

The patch from gerrit produces this.
Comment 57 Mike Kaganski 2016-08-17 10:18:02 UTC
I must notice that the Restart Manager isn't particularly reliable anyway. I see reports that it often cannot close some processes here and there for unknown reasons; that it fails to restart them (specifically, explorer.exe) on some occasions; that sometimes after choosing "do not close and restart", it brings that old notice from attachment 85393 [details], etc. As Michael Stahl said, that's Windows... I expect that to be a new source of "bug" reports.

What are other options (not necessarily mutually exclusive):

1. We can totally hide the dialogs and always reboot at the "resource busy" event. Some sources suggest that hiding the dialogs allows that. But that's not the MS-recommended way, it's against "MS-Logo" guidelenes if that matter, and it surely will make bad LO install process reputation for requirement to always reboot when it could be avoided.

2. If someone finds a way to unload the LO DLLs, (e.g. by using some interprocess communication that is established by those DLLs to request their unloading), then we may use a custom event to do that to make "resource busy" event less often - but that's not a good idea, because it will be error-prone, use more system resources, and may cause security issues.
Comment 58 Caolán McNamara 2016-08-17 13:48:02 UTC
Merged that effort to master (5-3) as https://cgit.freedesktop.org/libreoffice/core/commit/?id=190f0685c866b6232564c9d207456d3292d7a551

Lets give qa a while to test the install over the next week or so and if all goes well consider backporting to 5-2. Call this closed for now and if there are still lingering problems with the new approach open new bugs to deal with them as best we can, because this is now an unmanageable sprawling 50+ comment bug.
Comment 59 Mike Kaganski 2016-12-11 18:19:41 UTC
*** Bug 104585 has been marked as a duplicate of this bug. ***
Comment 60 Kumāra 2016-12-12 09:32:39 UTC
(In reply to Mike Kaganski from comment #59)
> *** Bug 104585 has been marked as a duplicate of this bug. ***

I can empathise with the new bug reporter. I recently experienced this bug again too, while upgrading to 5.2.3.3.
Comment 61 Mike Kaganski 2016-12-12 10:01:04 UTC
Just to sort things up:

That installer wants to close <any app here, including explorer.exe> *is not a bug*. If that program has locked a resource that installer needs to replace, it is obvious that is must stop doing so, otherwise a reboot will be necessary.

A program may lock a file by, e.g., opening it (say, you may open an editor to see LO license), or by using LO DLLs. These DLLs are there to allow e.g. explorer to show previews, and it is OK for programs to do that. But when a program have started using it, it's only that program that can decide when to release the DLL. If it doesn't do that, then we cannot force unloading the DLL, or bad things may happen when suddenly the program decides to continue using a data/function from the DLL that had been forcefully unloaded.

So, there's nothing to be done with the fact that LO asks (and will always ask) to unload programs, *including explorer*, in case when Windows tells the installer that those programs use necessary resources. End of story.
Comment 62 Michael Bauer 2016-12-12 10:11:51 UTC
There's always something that can be done. For instance, the problem only seems to occur when LO tries to install itself in one of Windows' default "Programs" folders. If I could code, I'd out in a step which makes LO, when it wants to flash this error at the user, install itself in C:\LibreOffice instead, problem solved for the end user...
Or just install it in C:\LibreOffice for everyone and be done with this lunacy.
Comment 63 Tobias Heilig 2017-01-26 13:39:10 UTC
Cannot install LibreOffice_5.2.5_Win_x86 due to this issue.
My System: Windows 10 Home, 64 bit, German
Comment 64 Mike Kaganski 2017-01-27 07:10:29 UTC
(In reply to Tobias Heilig from comment #63)

As mentioned in keywords, the fix is targeted to version 5.3.0. Comment 58 proposed to backport it to 5-2, but that hasn't happened.
Please don't reopen the bug unless you see the problem in a version where the bug is considered fixed.