Hi Everyone, as well as I have discussed on this LibreOffice - Users global list thread: http://listarchives.libreoffice.org/global/users/msg14444.html simply after installing LibreOffice 3.4.5 RC1: - on Windows XP, Home, SP3, updated, 32 bit, Ita GUIed, previous LibreOffice 3.3.2 uninstalled -> just, and only, after install, I have to run it twice to be able to see LibreOffice's gui because the first run didn't yield anything (on screen), but the second run (doble click) make LibreOffice to appear; all next (!) single runs make LibreOffice to appear; - on Windows XP, Professional, SP3, updated, 32 bit, Ita GUIed, previous old OpenOffice.org 2.4.0 uninstalled -> all goes well (i.e. LibreOffice appears always with only one (!) double click on his desktop icon); - on Windows Vista, Home Premium, SP2, updated, 32 bit, Ita GUIed, previous LibreOffice 3.3.2 uninstalled -> all goes well (i.e. LibreOffice appears always with only one (!) double click on his desktop icon); - on linux, kernel 2.6.38.6, x86-64, Gnome 2.30.2, Ita GUIed -> all goes well (if I don't remember badly). So my trouble seems to appear only in Windows XP PCs with previous LibreOffice installation (is it something linked to extensions registration?). But other people in the above thread experienced something like this in linux too. What do you think about? Have a nice evening, Carlo
I do not understand why it happened only on one system. One possibility is that it was something broken on this very particular machine. Another possibility that it happens when there is no LibreOffice version installed before => it migrates OpenOffice configuration or so. Tor, Fridrich, Andras, any ideas?
So this is a non-reproducible problem seen on a single machine?
Hello, I've got same problem (WinXP LibO 3.4.x) with previous versions. It seems to be due to updating database of previous extensions: if I removed all previous extensions before installing new version of LibO, I have no problem. I tried to identify which extension causes such problem, but I failed (lack of time).
[Reproducible] with Parallel Dev-Installation of "LibreOffice 3.5.0 Beta2- WIN7 Home Premium (64bit) German UI [Build-ID : 8589e48-760cc4d-f39cf3d-1b2857e-60db978] on my Desktop Can be reproduce simply (for me 100 % reproducible: 1. Close LibO 2. Rename user profile, for me "C:\Users\user\AppData\Roaming\LOdev\" to "C:\Users\user\AppData\Roaming\LOdev_X_\" 3. Launch LibO from WIN "ASll Programs - LOdev 3.5 - LOdev" > LibO Splash screen appears, you see several 1 line messages "Activating ........." Expected: Libo will start and show LibO StartCenter Actual: LibO does not start, terminates without any message when splash screen disappears. 4. Try 3. again > Now and in all future LibO will start without any problem Also [Reproducible] with "LibreOffice 3.4.5 RC1 - WIN7 Home Premium (64bit) German UI [Build ID: OOO340m1 (Build:501)]" and others, I saw it today after I had uninstalled 3.4.3, then installed 3.4.5 RC1. I also saw it on the desktop PC when I updated tor 3.4.5 from 3.4.4 To exclude possibility that it's related to an extension or similar I also will do a test with a Master build, soon (I can't remember whether I saw that for Master builds) @Petr:
@Petr: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
I think we are in the right way, but I am not sure having seen the splash screen in the first launch after installation. But may be I remember wrongly... ;-) Have a nice evening and an enthusiastic 2012 too! Carlo
NOT Reproducible with Server installation of Master "LOdev 3.5.0beta2+ – WIN7 Home Premium (64bit) ENGLISH UI [Build ID: 11b6fd5-7ef74e0-6f9c6e1]" Win-x86@6 - pull time 2011-12-28 22:03:29). First launch successful with default User profile (UserInstallation=$SYSUSERCONFIG/LOdev/3) and also (UserInstallation=$ORIGIN/../Data/settings) Only "Real complete installations" are affected.
Very interesting your last post Rainer. I forgot to say that in all installations of mine: - in this window http://www.libreoffice.org/assets/Uploads/EN-Project_images/install33win/dialog7.png I choose to "install all" (!) "Optional Components", but I leave "Additional language Packs" the default ones (English + Italian in Italian GUIed OSes); - in this one http://www.libreoffice.org/assets/Uploads/EN-Project_images/install33win/dialog8.png I use to check all check-boxes (Word, Excel and PowerPoint) in systems (all ones) that have not Microsoft Office already installed. Sorry for the lack in information and for the late integration of them.
@Petr: Sorry, forgot to assign
So - switching platform to Windows; after we've done our migration code, and fooled around registering components - we do a re-start (at least on Linux) - that is done by a very odd exit code (desktop/source/inc/exithelper.hxx) which would be trapped by our wrapper binary & cause a re-start. This is what desktop/source/app/app.cxx (restartOnMac) and other madness is. The re-start logic -should- be in: win32/source/officeloader/officeloader.cxx - checkout the E_NORMAL_RESTART stuff Why it is failing to re-start; I don't know :-) and have no windows to debug it with.
Tried very hard to reproduce it in my Windows XP and Windows 7 development boxes with no luck. The sad thing is that I know it happens because I have found this issue in the past. More hints to reproduce it will be appreciated.
*** Bug 43648 has been marked as a duplicate of this bug. ***
The process returns exit code 0x51 and as I see in the source code: E_NORMAL_RESTART = 81 So the exit code is not the problem.
Beta 3: I can confirm that LODev crashes while its first launch. Had to start LODev a second time. Working on Win7 64bit
@Marc Kaulisch: Crashes or simply terminates? Until now I failed to see the effect on a third XP 32Bit PC. 64Bit related? Or is the reason that that other PC never saw LibO before?
@ Rainer: Can't tell you if it technically is a crash or it terminates. I only see that LO is starting but not appearing on screen. Next start it works. I guess it is a termination as described above...
maybe something that can help you found the bug : I've installed libo 3.5rc3 and at first start it stopped later, i've had an extension directly into the folder C:\Program Files (x86)\LibreOffice 3.5\share\extensions\ then at the next start, it stopped too then it works fine if i remove the extension it stopped, and works fine copying a new time -> it stooped by this way the bug is reproducible
I have just realized that the bug is assigned to me. I switch it to Andras who works on Windows and has better chance to actually solve it.
*** Bug 46063 has been marked as a duplicate of this bug. ***
Updated today to LibreOfficePortable 3.5 from Portable 3.4.5 - first time LOPrtable starts as expected - Windows XP 32bit - the last days on my Win 7 64bit - I still had the problem that while the first start LO terminates
Reproducible with "LibreOffice 3.5.0 German UI/Locale [Build-ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735] on German WIN7 Home Premium (64bit) and sample profile from <Bug 46567 - Colours are changed after the installation to 3.5.0.rc3> <https://bugs.freedesktop.org/attachment.cgi?id=57595
But I am pretty sure that the reason for the problem is in the Program installation (may be Extensions), not in the profile. But you never know.
i have the same problem with libreoffice 3.4.6 RC2
sorry, the problem happens only when two versions of the French dictionary are in the extensions folder
could bug#49499 be related / a duplicate - it has a trace of apparent failure in soffice.exe at startup ?
IMHO, this bug describes the problem that LO does not start for the first time after update. You need to start it twice to get it running. It seems to be related to extensions re-registration. Though, the bug #49499 describes the problem that LO does not start at all. It usually helps to remove the user configuration. It might be related to extensions but the second start does not help in that case. The problems might be kind of related but they are probably different.
*** Bug 49627 has been marked as a duplicate of this bug. ***
Hi everyone, I am able to consistently reproduce this problem on both windows XP 32-bit and windows 7 64-bit machines with different versions of Libreoffice like 3.3, 3.4 and 3.5. I have a shared installation of LibreOffice installed on Windows machine. LibreOffice works fine for the user who installed and for any other user who logs-in, by default. But after installing any shared extension using unopkg --shared, when a user other than, the one who installed the extension, launches libreoffice, it crashes (rather terminates) at the first launch without any error message. The subsequent launch works fine. In the case of the new user logging in, the libreoffice user profile folder does not pre-exist at the first launch. But after the crash, the libreoffice user profile folder is generated and the subsequent launch works fine. This behavior happens only after installing shared extensions. Also for the user who installed the extension, if the Libreoffice profile folder is deleted/renamed, the Libreoffice crash/termination at first launch is reproducible. If not for shared extensions, the Libreoffice shared installation works fine and the crash/termination after the splash screen is not reproducible. So in my opinion, the problem appears to be due to registering of the extensions other than pre-installed extensions that come with Libreoffice installer.
There are too many comments that are IMHO unrelated to the original issue. I'm addressing only the original issue: After installation first launch terminates after splash screen In MSI installer there is a custom action called RegisterExtensions. It calls unopkg, and registers the extensions. The problem is that it runs without elevated privileges, because the whole installer logic was developed with Windows XP in mind, where there was no UAC. When I elevate the privilege of this custom action, LibreOffice does not terminate after the first launch! So this could be a solution. However, there is a problem. If I want to run RegisterExtensions with elevated privileges, I must put it before InstallFinalize, but we do not have Visual C++ runtime before InstallFinalize. It is circular dependency. I can install Visual C++ runtime just for unopkg, as a workaround, but first of all I would like to know, why RegisterExtensions is necessary at all. It seems that LibreOffice can work without extension registration by the installer (because apparently it does not work), the only problem that it needs to be started twice. The only difference I found between the good and wrong installations was the share\config\javasettingsunopkginstall.xml. In good installation it was filled with the details of my JRE.
What about statically linking unopkg with the c runtime?
(In reply to comment #30) > What about statically linking unopkg with the c runtime? I don't know how to do that. But this may be a good solution. BTW I wonder, why LibreOffice 3.3.x did not do this.
I know that we call unopkg also on Linux during installation. It creates a cache in /opt/libreoffice3.5/share/prereg/bundled. The cache is later used to update user configuration. The result is that user does not need to call unopkg for system extensions and the first start is much faster. I wonder if something similar should work also on Windows.
(In reply to comment #32) > I wonder if something similar should work also on Windows. The same works on Windows, when unopkg.exe is running with elevated privileges (in order to write the program's folder).
I dropped the idea of static linking, because we would need to statically link half of the world (unopkg.bin depends on sal3.dll which depends on msvcrt90.dll, too). I'm trying to make it work as a deferred custom action (no luck yet).
Andras Timar committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8783ead70cc2bc2a83bf473b0dfb51f3ee10b6da fdo#43989 let unopkg.exe run with elevated privileges during install
Andras Timar committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b33f69d2f45d92fd84cdff73d8baee0b14b40791&g=libreoffice-3-6 fdo#43989 let unopkg.exe run with elevated privileges during install It will be available in LibreOffice 3.6.
I tested the fix on clean Windows 7 32-bit, Windows 7 64-bit, and Windows 2008 Server R2.
*** Bug 50137 has been marked as a duplicate of this bug. ***
*** Bug 50790 has been marked as a duplicate of this bug. ***
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=55836370ffb70a34b888f81cdacdfede8fee29cf fdo#43989: Revert "win32-dont-attempt-restart.diff: Don't attempt to restart OOo after crash"
(In reply to comment #40) > fdo#43989: Revert "win32-dont-attempt-restart.diff: Don't attempt to restart > OOo after crash" now reverts the culprit that had completely prevented automatic restart on Windows in the first place
*** Bug 50820 has been marked as a duplicate of this bug. ***
Andras Timar committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=265242f06dbdd21dade56dc6fc6c1789f33ee966&g=libreoffice-3-5 fdo#43989 let unopkg.exe run with elevated privileges during install It will be available in LibreOffice 3.5.5.
*** Bug 51084 has been marked as a duplicate of this bug. ***
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4f61c0d2a32a6bfb28ba1c9ad1c00d984462f96b&g=libreoffice-3-6 fdo#43989: Revert "win32-dont-attempt-restart.diff: Don't attempt to restart OOo after crash" It will be available in LibreOffice 3.6.1.
The band-aid fix for bug 51252 in LO 3.6.0 RC4 (of no longer copying share/prereg/bundled data) means that this issue is back in LO 3.6.0 now, see <https://bugs.freedesktop.org/show_bug.cgi?id=51252#c56>. Will be fixed in LO 3.6.1. Workaround: manually restart LO.
*** Bug 53832 has been marked as a duplicate of this bug. ***