Problem description: Steps to reproduce: 1. have an old windowsxp installation with who-knows-what kind of misc. odd DLLs installed this will be hard to repro, but I immediately found two previously unproblematic windowsxp professional 32bit machines, that ran many of the recent years worth of libreoffice just fine. today came the upgrade to libreoffice 4.1 via the official signed installer packages (.msi), and the 4.1 would not start up, as a popup would complain that soffice.bin was reporting that c:\windows\system\STORE.DLL was not a valid application or file or something. that store.dll file existed on both of those machines, and uploading it to a virus checker (virustotal) showed that it was previously unknown to the online database there. filedate of store.dll dates back to 1993! although there are plenty of rather old files in windows\system\ (not NOT system32) on windowsxp machines, for compatibility reasons and other things, this store.dll file was almost the oldest in there, the file properties say that its supposedly by microsoft mail store layers from the year 1993 sha256 of store.dll file is: 757019059f3ca83aeb182385403a461342005423605b6502231ac6fcdf130598 analysis report can be found: <https://www.virustotal.com/en/file/757019059f3ca83aeb182385403a461342005423605b6502231ac6fcdf130598/analysis/> after renaming this file to something else, soffice.bin and the whole app starts up normally. Expected Behavior: Libreoffice code should make sure its not loading arbitrary DLLs accidentally or on purpose but only its own or well known legit DLLs and libraries and components. When searching google for libreoffice and store.dll there is actually some source code or source code filenames and paths coming up that are named storedllapi.h or similar stuff, I wonder if thats maybe got to do something with this bug <https://www.archlinux.org/packages/extra/x86_64/libreoffice-sdk/files/> .... usr/include/libreoffice/store/ usr/include/libreoffice/store/store.h usr/include/libreoffice/store/store.hxx usr/include/libreoffice/store/storedllapi.h usr/include/libreoffice/store/types.h .... Operating System: Windows XP Version: 4.1.0.4 release Last worked in: 4.0.4.2 release
Confirming.
This is a regression caused by <http://cgit.freedesktop.org/libreoffice/core/commit/?id=c9c963d3e6991d0dd73a95fc9734e38683d5be9c> "autoinstall ure private libraries" changing the name of the URE library from store3.dll to store.dll on Windows. That DLLs from LO's URE\bin directory can be shadowed by ones with identical names from various Windows system directories when running LO is a known gotcha. The easiest workaround might be to use the same "...lo.dll" naming scheme for those private URE DLLs that is already used for most of LO's non-URE DLLs.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=644c33a857c46d540202189228f519946dc33833 fdo#67313: Use "lo" suffix for private URE libs 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.
requested backport to libreoffice-4-1 towards LO 4.1.2 with <https://gerrit.libreoffice.org/#/c/5667/>
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6c4caf52724629d15a1d73c51c4f66e4f6011f7a&h=libreoffice-4-1 fdo#67313: Use "lo" suffix for private URE libs It will be available in LibreOffice 4.1.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.