I have the exception: System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception. at cppu.bootstrap(Reference<com::sun::star::uno::XComponentContext>* ) at uno.util.Bootstrap.bootstrap() With LibO 4.x 32bit the code was running fine. Now I'm using Windows 64 bit with LibreOffice 5.0.1.2 x64 bit and the code throw this exception. Code is compiled for framework 4.5.1 64 bit. I tried to set the UNO_PATH environment path but the problem still persist. How can I do? Regards
I can confirm the same exception at uno.util.Bootstrap.bootstrap from VB.NET application. Used to work fine on LibreOffice 4.x. This same error occurs when running LibreOffice_5.0.1_Win_x86 as well as LibreOffice_5.0.1_Win_x64. Tried to set the UNO_PATH environment as well as copying the missing URE folder from LibreOffice 4.x but it still fails. Any workaround suggestions until fixed?
NEW per comment 2.
*** Bug 94460 has been marked as a duplicate of this bug. ***
I can confirm that the bug is still present on version Fresh 5.0.4.2 Fresh I've found a workaround adding C:\Program Files (x86)\LibreOffice 5\program to PATH environment variable or by setting it via code in this way Environment.SetEnvironmentVariable("PATH", Environment.GetEnvironmentVariable("PATH") + @";" + unoPath, EnvironmentVariableTarget.Process); Ref: http://stackoverflow.com/questions/31856025/bootstrap-uno-api-libreoffice-exception P.S.: UNO_PATH environment variable seems useless. Just to add some detail the problem can be easily reproduced creating a new VB.NET or C# project, referencing cli_uno libraries and issuing the following command uno.util.Bootstrap.bootstrap();
Please don't change version to newer. Thanks.
Is this still a problem with recent 64-bit LO 5.1 or 5.2 beta/release-candidate builds?
Hi, I first reported this bug back in 2012. Please see Bug #46832. Worked for a while after it had been fixed then. However, have been unable to run later versions so instead I've been using OpenOffice. Today, I installed "LibreOffice_5.1.4_Win_x86.msi" on a my new 64bit Windows 10 and I still get the same exception... Regards, Christer
Throwing back to NEW.
Update: Added C:\Program Files (x86)\LibreOffice 5\program to PATH. Then it works! Actually, I used to do this in code at the beginning (with OpenOffice) but then I remarked it since it seemed like I didn't need it anymore. Well, now it seems like I do...
Since we have a bibisect repository for windows covering the branch where this regression was introduced, adding keyword 'bibisectRequest'. More info: https://wiki.documentfoundation.org/QA/Bibisect/Windows
Hi! I am using windows 10 64-bit and developing a C # .Net Framework 4.5 application, which has run on x64, so, you have installed LibreOffice 5.2.3 x64 with your respective sdk. I managed to replicate this error using the environment variable "UNO_PATH" and confirm that it still does not see fixes, but, I think the correct thing is to use the environment variable "PATH" (this is used in x86 and it works). However, when adding the environment variable as follows: string variableEntornoPATH = Environment.GetEnvironmentVariable("PATH"); Environment.SetEnvironmentVariable("PATH", variableEntornoPATH + ";C:\\Program Files\\LibreOffice 5\\program;"); It shows me the following error: The arithmetic operation has caused an overflow. It is Mapping_uno2cli (_uno_Mapping * mapping, Void ** ppOut, Void * pIn, _typelib_InterfaceTypeDescription * td) At com.sun.star.uno.Mapping.mapInterface (Mapping *, Void ** ppOut, Void * pInterface, Type * rType) In one.util.to_cli <class with :: sun :: star :: one :: XComponentContext> (Reference <com :: sun :: star :: one :: XComponentContext> * x) In one.util.Bootstrap.bootstrap() The problem is that there is no information about it and the only thing I found was the method code here: Https://github.com/LibreOffice/core/blob/master/cli_ure/source/uno_bridge/cli_bridge.cxx#L96 From what I can see in the code, it seems to me that there are problems with the pre-compilation flags. ptr= sri::GCHandle::ToIntPtr(sri::GCHandle::Alloc(cliI)) #ifdef _WIN32 .ToInt32(); #else /* defined(_WIN64) */ .ToInt64(); #endif Anyone have any solutions?
Thanks José! Thats it, you have found the bug! The solution is trivial: It is C++ Code and _WIN32 is always defined, even in Win64. ptr= sri::GCHandle::ToIntPtr(sri::GCHandle::Alloc(cliI)) #ifdef _WIN64 .ToInt64(); #else /* defined(_WIN32) */ .ToInt32(); #endif Thats it! In my eyes this Bug is critical: Because no one can use the SDK in 64 bit!
(In reply to C++ Guru from comment #13) > Thanks José! Thats it, you have found the bug! > > The solution is trivial: It is C++ Code and _WIN32 is always defined, even > in Win64. > > ptr= sri::GCHandle::ToIntPtr(sri::GCHandle::Alloc(cliI)) > #ifdef _WIN64 > .ToInt64(); > > #else /* defined(_WIN32) */ > .ToInt32(); > #endif > > > Thats it! > > > In my eyes this Bug is critical: Because no one can use the SDK in 64 bit! Hi, it's great you found the solution. Could you please submit a patch with the fix to gerrit ? https://wiki.documentfoundation.org/Development/gerrit/
Correct link: https://wiki.documentfoundation.org/Development/gerrit
Sorry, don't know how to do with gerrit. I have made a pull request: https://github.com/LibreOffice/core/pull/15
(In reply to C++ Guru from comment #16) > Sorry, don't know how to do with gerrit. > > I have made a pull request: > https://github.com/LibreOffice/core/pull/15 The pull request will not be accepted. GitHub is used as a read-only mirror. If you need help with gerrit, you can visit #libreoffice-dev https://wiki.documentfoundation.org/Website/IRC
ComputingDwarf committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3b2863596f26a8d32a5bc322bbbf51cad403c9fb tdf#94265: Correct the error It will be available in 5.4.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 C++ Guru from comment #16) > Sorry, don't know how to do with gerrit. > > I have made a pull request: > https://github.com/LibreOffice/core/pull/15 So, as an exception, I pushed that directly now, see comment 18, as I didn't find any corresponding Gerrit change at <https://gerrit.libreoffice.org/> but wouldn't want to lose this fix. @C++ Guru: Even if this is a small patch, please nevertheless send a license statement mail as explained at <https://wiki.documentfoundation.org/Development/Developers#License_Statements>. And thanks for the fix! (Setting as tentatively FIXED. Please somebody check it and set to VERIFIED accordingly.)
Hello, I tested the night build: http://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/2017-03-23_23.17.41/ It works, but only if I have both s64 installations of "LibreOffice 5.4 DEV" and "LibreOffice 5.3.1.2" and I set up the PATH environment variable for "C:\Program Files\LibreOfficeDev 5\program". If the previous version (5.3.2.1) is not presented on my PC (Windows 10 64-bit) I have the following exception: "'System.Runtime.InteropServices.SEHException' occurred in cli_cppuhelper.dll" when calling " XComponentContext localContext = uno.util.Bootstrap.bootstrap();" (when debugging using VS 2013 under a C# library .Net 4.5 executing as 64-bit process). My question is the following what have to be set up (what environnement variable and with which value) in order to use only LibreOffice 5.4 (or it is temporary as it is a developer version). Thanks.
Apparently C++ Guru was not CC'd on the report.. fixing that now.
(In reply to Aleksander Kasprzyk from comment #20) > My question is the following what have to be set up (what environnement > variable and with which value) in order to use only LibreOffice 5.4 (or it > is temporary as it is a developer version). the problem that CLI libraries can't be found sounds familiar... https://cgit.freedesktop.org/libreoffice/core/commit/?id=814ec7640fc2a529343e358ab4fd3b9a59d645ca the nightly builds for master do not use --enable-release-build, which means they don't install anything in C:/Windows or the registry. you can force it by installing with a parameter: msiexec /i *.msi WRITE_REGISTRY=1 i hope that that should put the CLI dlls into the "GAC" thing in C:/Windows. another way that should work for testing is to copy the cli_*.dll files from C:/LibreOffice/program/ directory into the directory of your client .exe file.
(In reply to Michael Stahl from comment #22) > you can force it by installing with a parameter: > > msiexec /i *.msi WRITE_REGISTRY=1 > > i hope that that should put the CLI dlls into the "GAC" thing in C:/Windows. > > another way that should work for testing is to copy the cli_*.dll files from > C:/LibreOffice/program/ directory into the directory of your client .exe > file. I had already copied cli_*.dll files to excecution folder of my program. And it didn't work. But with the option WRITE_REGISTRY=1 when installing MSI, it works :) I mark this bug as resolved. I'm waiting for the official release of the LibreOffice 5.4 (do you have any time-frame of this release?).
(In reply to Aleksander Kasprzyk from comment #23) > I'm waiting for the official release of the LibreOffice 5.4 (do you have any > time-frame of this release?). https://wiki.documentfoundation.org/ReleasePlan/5.4
Thanks (In reply to Buovjaga from comment #24) > (In reply to Aleksander Kasprzyk from comment #23) > > I'm waiting for the official release of the LibreOffice 5.4 (do you have any > > time-frame of this release?). > > https://wiki.documentfoundation.org/ReleasePlan/5.4
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=cfaba15c589f882cc0bcce5cd07bdf3d30f547f6 cli_ure: fix another bad _WIN64 check (related tdf#94265) It will be available in 5.4.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.
ComputingDwarf committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c1f3bd9a66554076e31cf96bdd2b788615e43710&h=libreoffice-5-2 tdf#94265: Correct the error It will be available in 5.2.7. 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.
ComputingDwarf committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4fbc70bcd790fad04ff158eafe899d47a0b624d6&h=libreoffice-5-3 tdf#94265: Correct the error It will be available in 5.3.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=81bf39616039280fc1f9b18db3ea6dc04ae9fc08&h=libreoffice-5-3 cli_ure: fix another bad _WIN64 check (related tdf#94265) It will be available in 5.3.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=32cee6bb153ede8a79b831ed0cf7a0256d73363c&h=libreoffice-5-2 cli_ure: fix another bad _WIN64 check (related tdf#94265) It will be available in 5.2.7. 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.
Hello, I have just tested with LibreOffice 5.2.7 and it works :) Thanks.
This still (or probably again) happens on 5.4.0.3.
(In reply to Jan P. from comment #32) > This still (or probably again) happens on 5.4.0.3. Aleksander: do you get the same result with 5.4?
(In reply to Jan P. from comment #32) > This still (or probably again) happens on 5.4.0.3. Jan: can you tell us more about how this happened to you?
(In reply to Buovjaga from comment #34) Hm. Not really. It's just like in the bug description/comments so far. I can tell you a bit about my environment: It's .NET 4.5 on Windows 8.1 64 bit; I compile for ‘Any CPU‘. The SDK for 32 bit LibreOffice works fine. (Of course only in connection with the 32 bit LibreOffice or OpenOffice and compiled for ‘X86’.) Perhaps you have any questions I can answer? Cheers, Jan
LibreOffice 5.4.4.2 is installed on a PC with no other LibreOffice versions. I use VB.NET 2015 and Framework 4.5.2. Error: Excepción producida: 'System.Runtime.InteropServices.SEHException' en cli_cppuhelper.dll workaround: Setting environment variable a sugested by APS (2016-01-13 14:57:56 UTC) fixed the problem. Dim unoPath As String = "C:\Program Files\LibreOffice 5\program" Environment.SetEnvironmentVariable("PATH", Environment.GetEnvironmentVariable("PATH") + ";" + unoPath, EnvironmentVariableTarget.Process)
Same issue for me on LO 6.0.2.1 64 bits win 10 using ironpython. Following code fixed the `System.Runtime.InteropServices.SEHException` : import os lo_path = r"C:\Program Files\LibreOffice\program" if lo_path not in os.environ["PATH"]: os.environ["PATH"] = "{}{};".format(os.environ["PATH"],lo_path) But when running : from uno.util import Bootstrap xcontext = Bootstrap.bootstrap() xcontext return an object instead of an XComponentContext but it is probably not related (might be an ironpython issue). case related here : https://ask.libreoffice.org/en/question/149748/cli-what-replace-deprecated-bootstrap-lo-602/
https://gerrit.libreoffice.org/52572
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b9d709e84728270acb00c3952551f5c608260e62 tdf#94265: use install directory on delay load failure 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 Commit Notification from comment #39) > Mike Kaganski committed a patch related to this issue. > It has been pushed to "master": > > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=b9d709e84728270acb00c3952551f5c608260e62 > > tdf#94265: use install directory on delay load failure > > 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. I installed the daily LibreOffice x64 build. It installed to a folder LibreOfficeDev. When I tried running one of the spreadsheet examples for CLI, I got the same error. When I tried renaming the LibreOfficeDev folder to be LibreOfficeDev, I still got the same error. Any ideas?
(In reply to Nick from comment #40) > I installed the daily LibreOffice x64 build. It installed to a folder > LibreOfficeDev. When I tried running one of the spreadsheet examples for > CLI, I got the same error. When I tried renaming the LibreOfficeDev folder > to be LibreOfficeDev, I still got the same error. Any ideas? Others: can you please test with a fresh master build?
The problem is still existing in 5.4.7.2 1) Install LibreOffice_5.4.7.2_Win_x86.msi 2) Install LibreOffice_5.4.7.2_Win_x86_sdk.msi 3) Create a VisualStudio 2015 Project: 3.1) Append the delivered example from the SDK Installation "SpreadsheetDocHelper.cs" 3.2) Project configuration = x86 3.3) Add useLegacyV2RuntimeActivationPolicy="true" to app.config 3.4) Reference the folowing libraries: LibreOffice_5.4.7.2_Win_x86_sdk\cli\cli_basetypes.dll LibreOffice_5.4.7.2_Win_x86_sdk\cli\cli_cppuhelper.dll LibreOffice_5.4.7.2_Win_x86_sdk\cli\cli_oootypes.dll LibreOffice_5.4.7.2_Win_x86_sdk\cli\cli_ure.dll LibreOffice_5.4.7.2_Win_x86_sdk\cli\cli_uretypes.dll 3.5) Adding code to add @"c:\Program Files (x86)\LibreOffice 5\program" to "PATH" 3.6) Adding code to add @"c:\Program Files (x86)\LibreOffice 5\program" to "UNO_PATH" 3.7) compile succefully 3.8) Unregister cli-Dlls from GAC using GACBrowser to force the application to use the CLI-dlls from the location of the executable. 3.9) Run: Exception occured on the line m_xContext = uno.util.Bootstrap.bootstrap(); cppu.bootstrap(Reference<com::sun::star::uno::XComponentContext>* ) uno.util.Bootstrap.bootstrap()\r\n bei SpreadsheetDocHelper.connect(String[] args) 3.10) Here is the complete output: \v4.0_4.0.0.0_de_b77a5c561934e089\mscorlib.resources.dll'. Module was built without symbols. The thread 0x1678 has exited with code 0 (0x0). The thread 0x1f34 has exited with code 0 (0x0). The thread 0x2944 has exited with code 0 (0x0). 'libreOfficeSdkTest.vshost.exe' (CLR v4.0.30319: libreOfficeSdkTest.vshost.exe): Loaded 'C:\ddtest\libreOfficeSdkTest\libreOfficeSdkTest\bin\x86\Debug\libreOfficeSdkTest.exe'. Symbols loaded. 'libreOfficeSdkTest.vshost.exe' (CLR v4.0.30319: libreOfficeSdkTest.vshost.exe): Loaded 'C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Configuration\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Configuration.dll'. Cannot find or open the PDB file. 'libreOfficeSdkTest.vshost.exe' (CLR v4.0.30319: libreOfficeSdkTest.vshost.exe): Loaded 'C:\ddtest\libreOfficeSdkTest\libreOfficeSdkTest\bin\x86\Debug\cli_uretypes.dll'. Module was built without symbols. 'libreOfficeSdkTest.vshost.exe' (CLR v4.0.30319: libreOfficeSdkTest.vshost.exe): Loaded 'C:\ddtest\libreOfficeSdkTest\libreOfficeSdkTest\bin\x86\Debug\cli_oootypes.dll'. Module was built without symbols. 'libreOfficeSdkTest.vshost.exe' (CLR v4.0.30319: libreOfficeSdkTest.vshost.exe): Loaded 'C:\ddtest\libreOfficeSdkTest\libreOfficeSdkTest\bin\x86\Debug\cli_cppuhelper.dll'. Cannot find or open the PDB file. 'libreOfficeSdkTest.vshost.exe' (CLR v4.0.30319: libreOfficeSdkTest.vshost.exe): Loaded 'C:\ddtest\libreOfficeSdkTest\libreOfficeSdkTest\bin\x86\Debug\cli_basetypes.dll'. Module was built without symbols. Exception thrown: 'System.Runtime.InteropServices.SEHException' in cli_cppuhelper.dll Additional information: Eine externe Komponente hat eine Ausnahme ausgelöst. Exception thrown: 'System.Runtime.InteropServices.SEHException' in libreOfficeSdkTest.exe Additional information: Eine externe Komponente hat eine Ausnahme ausgelöst. The thread 0x1d88 has exited with code 0 (0x0). The thread 0x2e4 has exited with code 0 (0x0). The program '[12584] libreOfficeSdkTest.vshost.exe: Program Trace' has exited with code 0 (0x0). The program '[12584] libreOfficeSdkTest.vshost.exe' has exited with code 0 (0x0).
regarding comment #42, if i read it correctly then that is never going to work and is a different problem than was reported in this bug initially. for reason why relying on PATH does not work, see the message of this commit: https://cgit.freedesktop.org/libreoffice/core/commit/?id=814ec7640fc2a529343e358ab4fd3b9a59d645ca -> closing, thanks Mike for the fix
regarding comment #40, the "LibreOfficeDev" name indicates that it does not install the CLI libraries in the system's GAC, not unless you force it with (iirc) WRITE_REGISTRY=1.