I had a fully working installation of LO 5.4.1.2 on my XP system. I saw there was a new version which I downloaded and installed after uninstalling my existing version using Revo Uninstaller. On trying to start LO the banner/logo appeared briefly and then disappeared. Nothing happened after that. I tried uninstalling and reinstalling to no avail. Then I read the release notes and saw that the Visual C++ runtime (2015) was a requirement. I didn't have it so I downloaded that and installed it successfully. Still LO 5.4.2.2 would not run. I tried reverting to 5.4.1.2 and that wouldn't run either until I uninstalled the VC++ runtime. Now I am back to where I started with a working installation. Can you suggest how I can get 5.4.2.2 working? If you need any more diagnostic information I would be happy tp provide it. Thanks for your time.
Microsoft Visual C++ 2015 Redistributable comes with the LibreOffice installer for Win XP as described here: https://wiki.documentfoundation.org/ReleaseNotes/5.4#Windows Could you please try unistalling LibreOffice, unistalling Visual C++ runtime and then installing LibreOffice again?
What is the Revo Uninstaller, and why is it required to uninstall LibreOffice that has its own supported means of uninstallation? (As aside, it's *not* required to uninstall previous LibreOffice versions prior to installing new. Doing so will require you to select required components again, while installing over existing installation allows to automatically upgrade already installed components.)
Xisco, I did as you asked and it's no better. I checked in Control Panel and the Visual C++ 2015 runtime is NOT there. Does the installer grab it from the internet because I have internet access disabled for security reasons? Mike, Revo is a free program that usually does a better job of uninstalling than most built-in uninstallers. You are right to say it's not needed but I have used it for years without issue. You are also right when you say about not needing to remove the old version. However, it IS necessary to do that with Linux so I usually do it that way as a matter of course. I hope that helps.
I don't think it help much since it seems to stop very early in the process but you can rename your LO directory profile (see https://wiki.documentfoundation.org/UserProfile#Windows) and give it a new try.
I should add that I had the same problem on my laptop which also runs XP. That already had the Visual C++ 2015 runtime and that did not work either. I downloaded a new copy, tested the checksum and tried again several times. It still didn't run after briefly flashing the banner. Task manager had no LO app running. I removed 5.4.2.2 and reinstalled 5.4.1.2 which works again. I had none of these issues with the Win10 64-bit version or the x86 version for Linux Mint: both run just fine. Having spent most of today trying to resolve this I've had enough and will resume tomorrow.
Reproduced on my XP VitrualBox VM.
Encountering the same problem, also with Windows XP SP3 32-bit.
Same problem. Version 5.4.2.2 deployed with WPKG tool on 10 XP stations and LO cannot start. Back manually with 5.4.1.2. Please test before publishing a new version !!!.
(In reply to Philippe Rossignol from comment #8) > Same problem. Version 5.4.2.2 deployed with WPKG tool on 10 XP stations and > LO cannot start. Back manually with 5.4.1.2. Please test before publishing a > new version !!!. There are less and less people (dev and qa) using XP so even if it's still supported by TDF (I must recognize I would have dropped support since XP has been released in 2002), it's longer to fix the problems on it. BTW, you can also deploy on 1 machine to test before deploying on 10 stations.
(In reply to Julien Nabet from comment #9) > (In reply to Philippe Rossignol from comment #8) > > Same problem. Version 5.4.2.2 deployed with WPKG tool on 10 XP stations and > > LO cannot start. Back manually with 5.4.1.2. Please test before publishing a > > new version !!!. > > There are less and less people (dev and qa) using XP so even if it's still > supported by TDF (I must recognize I would have dropped support since XP has > been released in 2002), it's longer to fix the problems on it. > > BTW, you can also deploy on 1 machine to test before deploying on 10 > stations. I fully agree about doing some preliminary tests before deploying ... but it's the first time that this type of problem occurs. Just one question : will the bug be fixed or do we keep 5.4.1.2 as the last LO version under XP SP3 ?. BTW, I know that XP iy very old and no more supported ... but in an industrial environment some embedded PCs are XP driven and cannot be replaced.
(In reply to Philippe Rossignol from comment #10) > ... > I fully agree about doing some preliminary tests before deploying ... but > it's the first time that this type of problem occurs. > Just one question : will the bug be fixed or do we keep 5.4.1.2 as the last > LO version under XP SP3 ?. > BTW, I know that XP iy very old and no more supported ... but in an > industrial environment some embedded PCs are XP driven and cannot be > replaced. I can't tell but perhaps Mike Kaganski (following comment 6) will find a fix. About industrial environment, I understand, sometimes editors won't release any new version and Citrix or similar solutions may be not so easy to use (and have also a cost). The cost to migrate may be too high so it can be difficult "to sell" the migration to the client but still: - Microsoft doesn't support anymore XP - there are certainly security flaws which won't be fixed - I'm not sure antivirus are still efficient for XP At last, you must know that for every LO major version, supported OS are debated. So it's possible WinXP won't be supported by LO in a not so far future.
That's right. The release notes say that 5.4 will be the last version of LibreOffice supported on XP. Even so, I am very grateful it is supported at the moment. Many other people have stopped producing supported applications for XP. I can see their point but I think XP has been the 'nicest' version of Windows so far.
*** Bug 113222 has been marked as a duplicate of this bug. ***
Andras: as Windows installer expert, thought you might be interested in this one. Since it's a regression and it prevents from any LO use, let's increase importance.
We have near 120 machines running under WinXP. It's very sad if LO will no longer work on this version of windows. There is same problem as topicstarter. After installing LO 5.3.6.1 (I haven't 5.4.1.2 version distributive) at first start program shown a warning that last start of LO was unsuccessful. I hope the bug will be fixed in next version.
Act1) Update LO to 5.4.2.2 from 5.4.2.1 for Win x86 (XP SP3) doesn't run. Act2) Uninstall and re-install 5.4.2.1 also doesn't run, while was running. Act3) Uninstall 5.4.2.1 and install 5.3.6 run. Act4) Uninstall 5.3.6 and install 5.4.1.2 run. Now I use 5.4.1.2.
Same problem with LibreOffice 5.4.2.2. A minor problem with LibreOffice 5.4.1.2. (if the last Windows XP users of this discussion can confirm it see Bug 113120) Back to LibreOffice 5.3.6.1 for me.
Same problem with LibreOffice 5.4.2.2 and I wonder if it has to do with how we installed windows updates. I've had to reinstall Windows XP Pro so I used a DVD I bought on ebay for $8 to apply all the windows updates it could offline. Could that be part of the problem?
(In reply to Jeff from comment #18) > and I wonder if it has to do with how we installed windows updates. I've had No, others have the same issue with 5.4.2 as well.
Created attachment 137174 [details] XPsp3 x86 WinDbg StackTrace of crash Attempted to get a SAL_LOG with a CygWin command terminal launch of TDF 5.4.2.2 x86 build. $ SAL_LOG=1 ./soffice.exe vsf_TestDocument.odt 2> tdf112928_debug.txt But the launch attempt crashes with .DMP file to into the LO program directory, SAL_LOG file was empty. Attaching a WinDbg (sdk7.1) stack trace with symbols and analyze -v
It would be interesting to know if a portable LibO 5.4.2 release such the one released by winPenPack.it does run or not under WinXP. here's the download page: https://sourceforge.net/projects/winpenpack/files/X-LibreOffice/releases/ it could be an interesting test to do to understand if the issue is during the installation process or affects the program itself.
Was just about to report this same issue. ;D LibreOffice 5.3.6.1 ran fine in my VM, but 5.4.2.2 wont go past showing the splash screen for a few seconds and then crashing. I assume there would be no benefit in attaching my user profile. (In reply to tommy27 from comment #21) > It would be interesting to know if a portable LibO 5.4.2 release such the > one released by winPenPack.it does run or not under WinXP. Tested it and it crashes as well. > it could be an interesting test to do to understand if the issue is during > the installation process or affects the program itself. Definitely affecting the program itself as when i extract it, the same result happens, and when it didnt work i decided to install it and still it didnt work.
*** Bug 113341 has been marked as a duplicate of this bug. ***
Created attachment 137198 [details] WinXPsp3 WinDbg stack trace with TDF symbols for 5.4.3.1 build Attaching a WinDbg stack trace and analysis of miniDump of crash on launch of 5.4.3.1 rc1 on WinXpsp3 with more complete TDF symbols. On a different Windows 10 host OS with another WinXPsp3 VM. Had pulled a full .reload of TDF symbols prior to uninstall of 5.4.0.3, they look fairly complete for this run against 5.4.3.1 build.
Created attachment 137199 [details] WinDbg stack trace using "ProcDump -w soffice.bin" for a 5.4.3.1 launch A trace with bit different approach, rather than just using the Breakpad miniDump, used "ProcDump -w soffice.bin" to wait and get a better look at the issue. This looks more helpful.
Stephan/Mike: last V Stuart Foote's bt indicates the pb is: 00e3f78c 002d9eed kernel32!CreateFileW+0x35f 00e3f7c0 013844c4 sal3!osl_openFile(struct _rtl_uString * strPath = 0x02e2b4b0, void ** pHandle = 0x02e8c914, unsigned long uFlags = 1)+0x7d [c:\cygwin64\home\buildslave\source\libo-core\sal\osl\w32\file.cxx @ 737] thought you might be interested in this bugtracker. Here's the line: 720 HANDLE hFile = CreateFileW( 721 o3tl::toW(rtl_uString_getStr(strSysPath)), 722 dwAccess, dwShare, nullptr, dwCreation, 0, nullptr); See https://opengrok.libreoffice.org/xref/core/sal/osl/w32/file.cxx#720 I tried to unwind this: "rtl_uString_getStr" returns "sal_Unicode *" see https://opengrok.libreoffice.org/xref/core/include/rtl/ustring.h#1414 then "sal_Unicode" is "wchar_t" for SAL_W32 138 #elif defined(SAL_W32) 139 typedef wchar_t sal_Unicode; see https://opengrok.libreoffice.org/xref/core/include/sal/types.h#137 o3tl::toW takes for input char16_t * and returns wchar_t * https://opengrok.libreoffice.org/xref/core/include/o3tl/char16_t2wchar_t.hxx#15 It seems we call o3tl::toW with an arg which is already wchar_t, could the implicit conversion to char16_t be the culprit?
(In reply to Julien Nabet from comment #26) While you are probably correct in where the problem is seen (my debug from last night indicates the failure of file operation inside dp_manager::PackageManagerImpl::create when it tries to access absent items in %userprofile%\LibreOffice\4\user\extensions\shared), there's no o3tl::toW in the failing code. What you see in code at your links is for master, while failing is code for 5.4, which is here: https://gerrit.libreoffice.org/gitweb?p=core.git;a=blob;f=sal/osl/w32/file.cxx;h=d7ef5623cd4ea17cb52fb4b73e96cf57f65c334d;hb=refs/heads/libreoffice-5-4#l737 Second: the code in LibreOffice uses LIBO_INTERNAL_ONLY && __cplusplus path in types.h, so sal_Unicode *is* char_16t for us. If it weren't, the code wouldn't compile. I'll continue debugging this.
(actually, my suspicion is on osl_getSystemPathFromFileURL_ and https://cgit.freedesktop.org/libreoffice/core/commit/?id=6abbad3c44809d9f8116992475c5efcaafc23dbf&h=libreoffice-5-4)
(In reply to Mike Kaganski from comment #28) > (actually, my suspicion is on osl_getSystemPathFromFileURL_ and > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=6abbad3c44809d9f8116992475c5efcaafc23dbf&h=libreoffice-5-4) Thank you for your feedback. Feel free to revert this commit if you think it's wrong but it's curious how something in sc part could impact LO in the whole.
(In reply to Julien Nabet from comment #29) No need to do that; my suspicion was clearly wrong :)
Well, the CreateFileW seems to be innocent. It fails as before, and further, the fileaccess::throw_handler is called from fileaccess::TaskManager::endTask. That's expected, and worked before, reaching exception handler down the call stack. The problem is that now it fails to initialize required data *before* the exception is thrown. An access violation system (not c++) exception (=SIGSEGV) in s_stub_computeObjectIdentifier *after* cppu_cppenv_getStaticOIdPart() - which seems to return uninitialized string (aRet.makeStringAndClear seems to be optimized away???). No idea what made this change of behaviour. Stephan, could you please take a look at this?
https://gerrit.libreoffice.org/43721/
Testing cloph's gerrit 43721 TB62 build 5.4.4.0.0+ on one of the same WinXPsp3, LODev comes up fine and all modules seem functional. =-ref-= http://dev-builds.libreoffice.org/daily/libreoffice-5-4/Win-x86@62-TDF/gerrit_43721/ Windows 10 Pro with VMWare workstation 12.5.7 host Windows XPsp3 x86, version 5.1 (buld 2600.xpsp_sp3_qfe.130503-00418) vm with Version: 5.4.4.0.0+ Build ID: 5ecedd1648c49741448a0e10b7f5b20a80668421 CPU threads: 2; OS: Windows 5.1; UI render: default; Locale: en-US (en_US); Calc: group
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c6ce662b444d713e45a2c326a81fc45685adbfb&h=libreoffice-5-4 tdf#112928: don't use "magic statics" for 5.4 (fails on WinXP) 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.
Backport request for 5-4-3: https://gerrit.libreoffice.org/43739
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-5-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d8522a7e0f98fb17ee0f1233b074bd8ba4089fde&h=libreoffice-5-4-3 tdf#112928: don't use "magic statics" for 5.4 (fails on WinXP) 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.
Done; 5.4.3 RC2 should have the fix. Thanks for the patch, Mike!
*** Bug 113476 has been marked as a duplicate of this bug. ***