Description: I've been using OneNote application from Microsoft for years (available as a part of Microsoft 365 or as a free app). It's an app for taking notes, making pictures, storing documents, etc. As a part of my daily workflow, I have attached several ods files directly to my notes. I read and edit them frequently by simply double-clicking them, when LibreOffice opens the file instantly. This has worked fine until yesterday with LO 24.2.x (I don't remember the exact version). After I upgraded to LO 25.2.1.2, this takes exactly 120 seconds until LO is open. OneNote remains frozen during that time. Steps to Reproduce: 1. Create a new ODS file in LO, fill the A1 cell with 123, and save it to some folder, e.g. C:\docs\test.ods. 2. Open OneNote application, create a new page and attach this file to the page. 3. Double-click the document icon in the page. Actual Results: OneNote freezes for 120s and after that LO is displayed with the document loaded. Expected Results: LO should be displayed instantly with the document loaded. Reproducible: Always User Profile Reset: Yes Additional Info: Other document types are opened instantly from OneNote: PDF, XLSX, ... Opening the C:\docs\test.ods from the file explorer works fine. If I double-click it, LO opens instantly. When I double-click the file in OneNote, I can see the two processes created immediately in the Task manager: soffice.bin and soffice.exe. After 120s, they are replaced by a single soffice.bin process. I tried unchecking "Load printer configuration with document" as suggested at https://www.reddit.com/r/libreoffice/comments/upf8nw/fixed_opening_documents_too_slow/ or https://ask.libreoffice.org/t/libre-office-slow-opening-a-document-hangs-for-45-to-60-seconds-for-writer-when-connected-to-the-internet/82665/17 to no avail. Version: 25.2.1.2 (X86_64) / LibreOffice Community Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: default; VCL: win Locale: sk-SK (sk_SK); UI: sk-SK Calc: threaded
This problem applies to any OL file, e.g., ODT, not just to ODS files.
As it is probably very rare for QA or devs to have access to OneNote, you could try bibisecting the issue with the win64-25.2 repository (although it could be a 24.8 bug as you say you jumped from 24.2 to 25.2). https://wiki.documentfoundation.org/QA/Bibisect https://wiki.documentfoundation.org/QA/Bibisect/Windows https://wiki.documentfoundation.org/QA/Bibisect/Bibisecting_tutorial
I am able to reproduce this issue on version 25.2.2.2, but I haven't bibisected it. Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Able to reproduce using Version: 25.2.1.2 (X86_64) / LibreOffice Community Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 12; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
A quick note: I did not really consider what it takes to bibisect this: one would have to temporarily associate .ods files with the instdir/program/soffice in the win64-25.2 bibisect repository specifically. Otherwise OneNote will open the wrong LibreOffice. So I guess one would have to go to the file association settings in Windows and change that.
I wasn't able to bibisect, as on each try I had to change the OS file associations and even then they were sometimes ignored by OneNote and the document was open in Excel. But I have additional info. I managed to retrieve the command line parameters of these two LibreOffice processes from the Task manager (in Details view, right-click a process, Create memory dump file, then open the dmp file in Visual Studio 2022). When I double-click an .ods file in Windows file explorer, all works correctly (it opens immediately) and the parameters are: Process Name: C:\Program Files\LibreOffice\program\soffice.exe -o "C:\Users\USER\OneDrive\Desktop\Test.ods" Process Name: C:\Program Files\LibreOffice\program\soffice.bin "-o" "C:\Users\USER\OneDrive\Desktop\Test.ods" "-env:OOO_CWD=2C:\\Users\\USER\\OneDrive\\Desktop" But when I double-click the file in OneNote, the parameters are: Process Name: C:\Program Files\LibreOffice\program\soffice.exe --nodefault --nologo -Embedding Process Name: C:\Program Files\LibreOffice\program\soffice.bin "--nodefault" "--nologo" "-Embedding" "-env:OOO_CWD=2C:\\WINDOWS\\system32" After 120sec, the file is open. It seems like this -Embedding parameter causes problems. According to https://help.libreoffice.org/latest/en-US/text/shared/guide/start_parameters.html, this parameter is COM+ related; Windows only. I created a testing .bat file with this content: "C:\Program Files\LibreOffice\program\soffice.exe" --nodefault --nologo -Embedding pause It starts these two processes and nothing happens, they run forever and I need to kill them.
The "-Embedding" arg has been ignored for a very long time. But what it does cause, is LibreOffice tries to print out a message telling you that the argument is deprecated and should not be used anymore. I am guessing that, if there is no console attached to the process, then trying to print out that message will block the process forever. The relevant source code is in: desktop/source/app/cmdlineargs.cxx:442: /* fdo#57203 ignore -Embedding on Windows desktop/source/app/cmdlineargs.cxx:445: else if ( oArg == "Embedding" ) desktop/source/app/cmdlinehelp.cxx:184: " -Embedding Ignored (COM+ related; Windows only). \n" if anyone wants to hazard some kind of workaround.
Please allow me to jump in. I am a LO user in Japan, and I have a similar issue with LO 25.2.5 (Japanese) and finally arrived at this thread. I think my issue is the same one as discussed in this thread. Here is my problem: Step1: Create a odx document fine (x = p, s, or t) on Windows11. Step2: Attach the file to a note page in OneNote (Desktop). Step3: Try to open the attached odx file by double-clicking the file icon in the OneNote note page. What happens is: If using LO 25.2.5 to open the file, it takes 120 seconds until LO program appears on the screen and open the document. If using an older LO 24.8.7, it takes just 10 seconds, which looks normal. If using the newest version LO 25.8.1, it takes 120 seconds as well. So, I think until version 24.8, opening odx files attached to OneNote worked fine, but after version 25.x, it takes very long time (120 s) and even with the newest version 25.8, this issue remains. If my issue is consistent with the topic discussed in this thread, which I hope, please keep taking care of it. Thank you
As we have code pointers in comment 7, let's remove the request to bibisect.
(In reply to Buovjaga from comment #9) > As we have code pointers in comment 7, let's remove the request to bibisect. Hi, may I understand that this issue is already recognized and its bug-fixing process is underway? Thank you.
(In reply to ayoshida from comment #10) > (In reply to Buovjaga from comment #9) > > As we have code pointers in comment 7, let's remove the request to bibisect. > > Hi, may I understand that this issue is already recognized and its > bug-fixing process is underway? It has been recognised, but the fixing is not underway.
(In reply to Buovjaga from comment #11) > (In reply to ayoshida from comment #10) > > (In reply to Buovjaga from comment #9) > > > As we have code pointers in comment 7, let's remove the request to bibisect. > > > > Hi, may I understand that this issue is already recognized and its > > bug-fixing process is underway? > > It has been recognised, but the fixing is not underway. Thank you. I look forward to getting this issue fixed in the future releases.
Does anyone know if the fixing process for this bug has started? Please let mw know.
If someone could attach a debugger to the soffice process while it is stuck, and get a stack trace of where it is stuck, that would be very helpful. Right now, none of the developers have the ability to replicate this bug, and no real idea where things are getting stuck.
I attached Visual Studio 2026 during this 120 sec freeze to soffice and pressed the Break button. As I wrote earlier, there are two processes running during this 120 sec period. The first one is soffice.exe for which the call stack was: win32u.dll!NtUserMsgWaitForMultipleObjectsEx() soffice.exe!00007ff6919f4600() soffice.exe!00007ff691a0745e() kernel32.dll!BaseThreadInitThunk() ntdll.dll!RtlUserThreadStart() The second one is soffice.bin: ntdll.dll!NtWaitForMultipleObjects() KernelBase.dll!WaitForMultipleObjectsEx() combase.dll!DefaultWaitForHandles(unsigned long dwFlags=8, unsigned long dwTimeout=250, unsigned long cHandles=1, void * * pHandles, unsigned long * pdwIndex=0x00000044f9cefa58) Line 38 at onecore\com\combase\dcomrem\sync.cxx(38) combase.dll!CoWaitForMultipleHandles(unsigned long dwFlags=8, unsigned long dwTimeout=250, unsigned long cHandles=1, void * * pHandles=0x00000044f9cefa50, unsigned long * lpdwindex=0x00000044f9cefa58) Line 123 at onecore\com\combase\dcomrem\sync.cxx(123) sal3.dll!00007ffd00fc52b3() mergedlo.dll!00007ffcd4377021() salhelper3MSC.dll!00007ffd06de2ea1() salhelper3MSC.dll!00007ffd06de2b08() sal3.dll!00007ffd00fe8443() ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() kernel32.dll!BaseThreadInitThunk() ntdll.dll!RtlUserThreadStart() I don't know if it's of any help. I'm a .NET developer, so I'm not experienced with native code debugging. If there is anything else I can check, just let me know.
Thanks, Peter. You may look into this: https://wiki.documentfoundation.org/Development/How_to_debug#Debugging_with_WinDbg_or_Visual_Studio_(on_Windows) https://wiki.documentfoundation.org/Development/How_to_debug#Debugging_release_builds At the moment we don't have daily builds with debug symbols, so release builds have to be used.
(In reply to Peter M from comment #15) > I attached Visual Studio 2026 during this 120 sec freeze to soffice and > pressed the Break button. As I wrote earlier, there are two processes > running during this 120 sec period. > Thank you Peter, that was pretty close. What we want is the second one (soffice.bin), which should have multiple threads waiting - unfortunately the one you posted was a background thread. Visual Studio should be capable of displaying each of the threads a process has - there is a combobox selector near the top menu bar.
Created attachment 205273 [details] diagram with all runnignthreads when the freeze is pending
Created attachment 205274 [details] diagram with all runnignthreads when the freeze is pending Here are some threads that I think could be relevant. Also, attached is a diagram with all threads running. ********Worker Thread Crash Watchdog ntdll.dll!NtWaitForMultipleObjects() KernelBase.dll!WaitForMultipleObjectsEx() combase.dll!DefaultWaitForHandles(unsigned long dwFlags=8, unsigned long dwTimeout=250, unsigned long cHandles=1, void * * pHandles, unsigned long * pdwIndex=0x000000f59d8ef8f8) Line 38 at onecore\com\combase\dcomrem\sync.cxx(38) combase.dll!CoWaitForMultipleHandles(unsigned long dwFlags=8, unsigned long dwTimeout=250, unsigned long cHandles=1, void * * pHandles=0x000000f59d8ef8f0, unsigned long * lpdwindex=0x000000f59d8ef8f8) Line 123 at onecore\com\combase\dcomrem\sync.cxx(123) [Inline Frame] sal3.dll!sal::systools::WaitForMultipleObjects_COMDispatch(unsigned long) Line 26 at C:\cygwin64\home\buildslave\source\libo-core\include\systools\win32\wait_for_multiple_objects.hxx(26) sal3.dll!osl_waitCondition(void * Condition=0x0000000000000518, const TimeValue * pTimeout) Line 79 at C:\cygwin64\home\buildslave\source\libo-core\sal\osl\w32\conditn.cxx(79) [Inline Frame] mergedlo.dll!osl::Condition::wait(const TimeValue *) Line 123 at C:\cygwin64\home\buildslave\source\libo-core\include\osl\conditn.hxx(123) mergedlo.dll!WatchdogThread::execute() Line 130 at C:\cygwin64\home\buildslave\source\libo-core\vcl\source\app\watchdog.cxx(130) salhelper3MSC.dll!salhelper::Thread::run() Line 39 at C:\cygwin64\home\buildslave\source\libo-core\salhelper\source\thread.cxx(39) salhelper3MSC.dll!threadFunc(void * param=0x00000227d1580220) Line 190 at C:\cygwin64\home\buildslave\source\libo-core\include\osl\thread.hxx(190) sal3.dll!oslWorkerWrapperFunction(void * pData=0x00000227d157fe50) Line 67 at C:\cygwin64\home\buildslave\source\libo-core\sal\osl\w32\thread.cxx(67) ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() kernel32.dll!BaseThreadInitThunk() ntdll.dll!RtlUserThreadStart() ********Worker Thread VCL Main win32u.dll!NtUserGetMessage() user32.dll!GetMessageW() vclplug_winlo.dll!ImplSalYield(bool bWait=true, bool bHandleAllCurrentEvents=false) Line 498 at C:\cygwin64\home\buildslave\source\libo-core\vcl\win\app\salinst.cxx(498) vclplug_winlo.dll!WinSalInstance::DoYield(bool bWait=true, bool bHandleAllCurrentEvents=false) Line 547 at C:\cygwin64\home\buildslave\source\libo-core\vcl\win\app\salinst.cxx(547) mergedlo.dll!ImplYield(bool i_bWait=true, bool i_bAllEvents=false) Line 388 at C:\cygwin64\home\buildslave\source\libo-core\vcl\source\app\svapp.cxx(388) mergedlo.dll!Application::Execute() Line 361 at C:\cygwin64\home\buildslave\source\libo-core\vcl\source\app\svapp.cxx(361) mergedlo.dll!desktop::Desktop::Main() Line 1677 at C:\cygwin64\home\buildslave\source\libo-core\desktop\source\app\app.cxx(1677) mergedlo.dll!ImplSVMain() Line 231 at C:\cygwin64\home\buildslave\source\libo-core\vcl\source\app\svmain.cxx(231) [Inline Frame] mergedlo.dll!SVMain() Line 249 at C:\cygwin64\home\buildslave\source\libo-core\vcl\source\app\svmain.cxx(249) mergedlo.dll!soffice_main() Line 122 at C:\cygwin64\home\buildslave\source\libo-core\desktop\source\app\sofficemain.cxx(122) [Inline Frame] soffice.bin!sal_main() Line 51 at C:\cygwin64\home\buildslave\source\libo-core\desktop\source\app\main.c(51) soffice.bin!main(int argc, char * * argv) Line 49 at C:\cygwin64\home\buildslave\source\libo-core\desktop\source\app\main.c(49) [Inline Frame] soffice.bin!invoke_main() Line 78 at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(78) soffice.bin!__scrt_common_main_seh() Line 288 at D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl(288) kernel32.dll!BaseThreadInitThunk() ntdll.dll!RtlUserThreadStart() ********Worker Thread PipeIPC ntdll.dll!NtWaitForSingleObject() KernelBase.dll!WaitForSingleObjectEx() KernelBase.dll!GetOverlappedResult() sal3.dll!osl_acceptPipe(oslPipeImpl * pPipe=0x00000227d1530940) Line 314 at C:\cygwin64\home\buildslave\source\libo-core\sal\osl\w32\pipe.cxx(314) [Inline Frame] mergedlo.dll!osl::Pipe::accept(osl::StreamPipe &) Line 155 at C:\cygwin64\home\buildslave\source\libo-core\include\osl\pipe.hxx(155) mergedlo.dll!desktop::PipeIpcThread::execute() Line 1127 at C:\cygwin64\home\buildslave\source\libo-core\desktop\source\app\officeipcthread.cxx(1127) salhelper3MSC.dll!salhelper::Thread::run() Line 39 at C:\cygwin64\home\buildslave\source\libo-core\salhelper\source\thread.cxx(39) salhelper3MSC.dll!threadFunc(void * param=0x00000227d15d1980) Line 190 at C:\cygwin64\home\buildslave\source\libo-core\include\osl\thread.hxx(190) sal3.dll!oslWorkerWrapperFunction(void * pData=0x00000227cb96ce80) Line 67 at C:\cygwin64\home\buildslave\source\libo-core\sal\osl\w32\thread.cxx(67) ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() kernel32.dll!BaseThreadInitThunk() ntdll.dll!RtlUserThreadStart() ******** Worker Thread configmgrWriter ntdll.dll!NtWaitForAlertByThreadId() ntdll.dll!RtlSleepConditionVariableSRW() KernelBase.dll!SleepConditionVariableSRW() [Inline Frame] msvcp140.dll!_Primitive_wait_for(_Cnd_internal_imp_t * const) Line 14 at D:\a\_work\1\s\src\vctools\crt\github\stl\src\primitives.hpp(14) [Inline Frame] msvcp140.dll!_Primitive_wait(_Cnd_internal_imp_t * const) Line 18 at D:\a\_work\1\s\src\vctools\crt\github\stl\src\primitives.hpp(18) msvcp140.dll!_Cnd_wait(_Cnd_internal_imp_t * cond, _Mtx_internal_imp_t * mtx=0x00000227d1a76620) Line 58 at D:\a\_work\1\s\src\vctools\crt\github\stl\src\cond.cpp(58) [Inline Frame] mergedlo.dll!std::condition_variable::wait(std::unique_lock<std::mutex> &) Line 595 at C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.29.30133\include\mutex(595) mergedlo.dll!configmgr::Components::WriteThread::execute() Line 198 at C:\cygwin64\home\buildslave\source\libo-core\configmgr\source\components.cxx(198) salhelper3MSC.dll!salhelper::Thread::run() Line 39 at C:\cygwin64\home\buildslave\source\libo-core\salhelper\source\thread.cxx(39) salhelper3MSC.dll!threadFunc(void * param=0x00000227d1a765e0) Line 190 at C:\cygwin64\home\buildslave\source\libo-core\include\osl\thread.hxx(190) sal3.dll!oslWorkerWrapperFunction(void * pData=0x00000227d162abc0) Line 67 at C:\cygwin64\home\buildslave\source\libo-core\sal\osl\w32\thread.cxx(67) ucrtbase.dll!thread_start<unsigned int (__cdecl*)(void *),1>() kernel32.dll!BaseThreadInitThunk() ntdll.dll!RtlUserThreadStart() ******** Worker Thread combase.dll!CRpcThreadCache::RpcWorkerThreadEntry ntdll.dll!NtWaitForMultipleObjects() KernelBase.dll!WaitForMultipleObjectsEx() [Inline Frame] combase.dll!WaitCoalesced(void *) Line 70 at onecore\com\published\comutils\coalescedwait.cxx(70) combase.dll!CROIDTable::WorkerThreadLoop(void * param=0x0000000000000000) Line 1716 at onecore\com\combase\dcomrem\refcache.cxx(1716) combase.dll!CRpcThread::WorkerLoop() Line 283 at onecore\com\combase\dcomrem\threads.cxx(283) combase.dll!CRpcThreadCache::RpcWorkerThreadEntry(void * param=0x00000227d1a2bf70) Line 77 at onecore\com\combase\dcomrem\threads.cxx(77) kernel32.dll!BaseThreadInitThunk() ntdll.dll!RtlUserThreadStart() ******** Worker Thread mergedlo.dll!google_breakpad::ExceptionHandler::ExceptionHandlerThreadMain ntdll.dll!NtWaitForSingleObject() KernelBase.dll!WaitForSingleObjectEx() mergedlo.dll!google_breakpad::ExceptionHandler::ExceptionHandlerThreadMain(void * lpParameter=0x00000227cb8a6bc0) Line 392 at E:\r\workdir\UnpackedTarball\breakpad\src\client\windows\handler\exception_handler.cc(392) kernel32.dll!BaseThreadInitThunk() ntdll.dll!RtlUserThreadStart()
Thank you very much for that Mark. Sadly, that does not pinpoint the problem. That looks perfectly normal, nothing is blocked. I have no idea what is going wrong.
I understand. Are you on Windows? Did you try it with OneNote? If not, OneNote is free, you can install it from https://play.google.com/store/apps/details?id=com.microsoft.office.onenote The repro steps are simple and described in my first post here. No need to learn OneNote. You can then uninstall it quickly. Of course, I'll be glad to provide additional info if needed.
Sorry, wrong download link. It should be https://apps.microsoft.com/detail/xpffzhvgqwwlhb