Description: I have a strange problem with LibreOffice 7.3.0.3 in our school (but it also happened on previous versions of LibreOffice). When I open any document for the first time from login in into user account everything works fine. But If I’m trying to open a second document (previously closing the previous one) nothing happened. I can see in task manager (it’s a Windows 10 Pro) that LibreOffice processes last and takes some of CPU. If I kill all these processes I can open again a new document. I tried removing a LibreOffice folder from %appdata% of that user but it doesn’t help. Computer is joined into domain and the user is logging into domain account with mobile profile and folder redirections (including Desktop from the documents are opening and AppData folder). This is probably something not ok with LibreOffice in this particular computer, because I tried also logging as a different domain user and there are the same symptoms. Only for Administrator account that doesn’t have a mobile profile and folder redirection everything works fine on that particular computer. What is also interesting, I tried logging in into the same user from another computer also with LibreOffice and there everything works fine. Steps to Reproduce: 1. Log in into the account 2. Open any document 3. Close that document 4. Try to open another document (without success) Actual Results: LibreOffice processes last in TaskManager and it in some kind preventing from running a new instance Expected Results: LibreOffice processes are closed correctly and I'm able to oen another document Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.3.0.3 (x64) / LibreOffice Community Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: pl-PL Calc: CL
Created attachment 178429 [details] Backtrace of hanged process I'm not sure if I created this backtrace correctly (as in instruction there is no case for hanged process). I just attached to the changed process for a while and then break. After that analysis has been done.
Thanks for the backtrace. Unfortunately, it doesn't look useful. Could you please try to obtain a minidump - https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg#Producing_a_mini_dump Do that nearly the same way as you did for WinDBG: let the process to hang a little, then run > procdump.exe soffice.bin (note that no additional command line options needed, like '-h' - since we don't know if the process is actually hung, or if it just waits indefinitely in the background). The command should create a minidump file, and print its path. Please attach it here. Thank you!
Also, you may check proxy and set to None, if that's in use. I set Needinfo because hardly will anyone come up with a solution, unless you find out why LO doesn't close.
I tried to create a minidump but without success. I opened a LibreOffice then run "procdump64 soffice.bin -h" and then I closed a LO window but procdump64 still displaying only "Press Ctrl-C to end monitoring without terminating the process". So I pressed Ctrl-C but then I only saw a message "Dump count not reached" and nothing has been produced (I mean no debug logs or something). Sorry, I'm not an expert in terms of debugging. Could you assist me and provide more information what I'm done wrong and what I should do? I also tried change a proxy settings to None but without effect. Btw. do I need specially compiled version of LO or can I use that one comes with MSI installer package?
(In reply to Michał Piotrowski from comment #4) > I opened a LibreOffice then run "procdump64 soffice.bin -h" Please look at what I wrote in comment #2: > ... then run > > > procdump.exe soffice.bin > > (note that no additional command line options needed, like '-h' - since we > don't know if the process is actually hung, or if it just waits indefinitely > in the background).
Created attachment 178452 [details] Minidump
(In reply to Mike Kaganski from comment #5) > (In reply to Michał Piotrowski from comment #4) > > I opened a LibreOffice then run "procdump64 soffice.bin -h" > > Please look at what I wrote in comment #2: > > ... then run > > > > > procdump.exe soffice.bin > > > > (note that no additional command line options needed, like '-h' - since we > > don't know if the process is actually hung, or if it just waits indefinitely > > in the background). Very sorry, you indeed point me what I should do. My bad.
(In reply to Michał Piotrowski from comment #6) > Minidump Great! The problematic call stack is > ntdll.dll!NtCreateFile() Unknown > KERNELBASE.dll!00007ff9f54831e2() Unknown > [Inline Frame] sal3.dll!create_dir_with_callback(_rtl_uString *) Line 556 C++ > sal3.dll!create_dir_recursively_(_rtl_uString * dir_path, void(*)(void *, _rtl_uString *) aDirectoryCreationCallbackFunc, void * pData) Line 598 C++ > sal3.dll!osl_createDirectoryPath(_rtl_uString * aDirectoryUrl, void(*)(void *, _rtl_uString *) aDirectoryCreationCallbackFunc, void * pData) Line 639 C++ > [Inline Frame] mergedlo.dll!osl::Directory::createPath(const rtl::OUString &) Line 1940 C++ > mergedlo.dll!comphelper::BackupFileHelper::tryPush_Files(const std::set<rtl::OUString,std::less<rtl::OUString>,std::allocator<rtl::OUString>> & rDirs, const std::set<std::pair<rtl::OUString,rtl::OUString>,std::less<std::pair<rtl::OUString,rtl::OUString>>,std::allocator<std::pair<rtl::OUString,rtl::OUString>>> & rFiles, std::basic_string_view<char16_t,std::char_traits<char16_t>> rSourceURL, const rtl::OUString & rTargetURL) Line 2032 C++ > mergedlo.dll!comphelper::BackupFileHelper::tryPush_Files(const std::set<rtl::OUString,std::less<rtl::OUString>,std::allocator<rtl::OUString>> & rDirs, const std::set<std::pair<rtl::OUString,rtl::OUString>,std::less<std::pair<rtl::OUString,rtl::OUString>>,std::allocator<std::pair<rtl::OUString,rtl::OUString>>> & rFiles, std::basic_string_view<char16_t,std::char_traits<char16_t>> rSourceURL, const rtl::OUString & rTargetURL) Line 2056 C++ > mergedlo.dll!comphelper::BackupFileHelper::tryPush_Files(const std::set<rtl::OUString,std::less<rtl::OUString>,std::allocator<rtl::OUString>> & rDirs, const std::set<std::pair<rtl::OUString,rtl::OUString>,std::less<std::pair<rtl::OUString,rtl::OUString>>,std::allocator<std::pair<rtl::OUString,rtl::OUString>>> & rFiles, std::basic_string_view<char16_t,std::char_traits<char16_t>> rSourceURL, const rtl::OUString & rTargetURL) Line 2056 C++ > mergedlo.dll!comphelper::BackupFileHelper::tryPush_Files(const std::set<rtl::OUString,std::less<rtl::OUString>,std::allocator<rtl::OUString>> & rDirs, const std::set<std::pair<rtl::OUString,rtl::OUString>,std::less<std::pair<rtl::OUString,rtl::OUString>>,std::allocator<std::pair<rtl::OUString,rtl::OUString>>> & rFiles, std::basic_string_view<char16_t,std::char_traits<char16_t>> rSourceURL, const rtl::OUString & rTargetURL) Line 2056 C++ > mergedlo.dll!comphelper::BackupFileHelper::tryPush() Line 1656 C++ > mergedlo.dll!desktop::Desktop::doShutdown() Line 1687 C++ > mergedlo.dll!desktop::Desktop::Main() Line 1611 C++ > mergedlo.dll!ImplSVMain() Line 199 C++ > [Inline Frame] mergedlo.dll!SVMain() Line 231 C++ > mergedlo.dll!soffice_main() Line 98 C++ > [Inline Frame] soffice.bin!sal_main() Line 49 C > soffice.bin!main(int argc, char * * argv) Line 47 C > [Inline Frame] soffice.bin!invoke_main() Line 78 C++ > soffice.bin!__scrt_common_main_seh() Line 288 C++ > kernel32.dll!BaseThreadInitThunk() Unknown > ntdll.dll!RtlUserThreadStart() Unknown It seems to hang at trying to backup the user configuration in Desktop::doShutdown [1]. The call stack ends inside NtCreateFile (itself inside CreateDirectoryW), which is very unusual to hang - but unfortunately, the minidump doesn't include the process memory, only stack memory, which doesn't allow to inspect which path it tries to create. Creating a dump with full process memory (like 'procdump64 soffice.bin -ma' [2]) would produce way too large dump, and additionally could be unsafe (I have no idea what could it contain in addition to the information we need); so I'd suggest you to try another Sysinternals tool: Process Monitor [3] - to try to see which paths it accesses from the point where it gets closed, up to the hang point. Then seeing those paths could shed some light, and maybe allow you to see some permission issues? [1] https://opengrok.libreoffice.org/xref/core/desktop/source/app/app.cxx?r=229123ccc6f90ebf66b3e659bebbd53f8a9bdd3a#1686 [2] https://docs.microsoft.com/en-us/sysinternals/downloads/procdump [3] https://docs.microsoft.com/en-us/sysinternals/downloads/procmon
Thanks for advice. I used a ProcMon and I sow LO trying to save one file inside %appdata%/LibreOffice but ProcMon shows a NAME_COLLISION for that file what indicate a problems with offline files in Windows. And indeed, space for offline files was full (but I'm not sure if it was a cause) so I increased a space for offline files and cleared a "cache" (or something like that for offline files). After that LO can close correctly but another strange thing start happen: after opening and closing a few documents it starts to hangs on opening (also tried to access or write some files). My temporal solution is to disable offline files at all and it solves this problems correctly but I must to investigate it later. Btw. probably I can be not alone in that kind of problems, so maybe it's a good idea to set some kind of timeout (number of tries) for saving this user configuration in LO?
(In reply to Michał Piotrowski from comment #9) > I increased a space for offline files and cleared a "cache" (or > something like that for offline files). > After that LO can close correctly Great that you found it! > but another strange thing start happen: > after opening and closing a few documents it starts to hangs on opening > (also tried to access or write some files). > My temporal solution is to disable offline files at all and it solves this > problems correctly but I must to investigate it later. From my times of administrating a Windows-based domain on my ex-job, I remember struggling with RDP-related quotas, roaming profiles, and some applications that regularly made those blow (including AutoCAD and OOo/LO). I don't remember the RDP-related details (it was more than 7 years ago - time flies...), but I do remember excluding some program-specific %appdata% subfolders from roaming profile content in respective group policies (adding exclusion of paths). Yes, the configuration of that is not straightforward. > Btw. probably I can be not alone in that kind of problems, so maybe it's a > good idea to set some kind of timeout (number of tries) for saving this user > configuration in LO? No, not at this time, since it's still not affecting many, and at this point, it's better to create a FAQ at wiki ( https://wiki.documentfoundation.org/Faq/General ) - I ask you to do that when you have some time, to dump the information you gathered. At some point, the FAQ could enable to see the problem as a whole; but implementing a "timeout" means great additional complexity at the code that is really fragile and critical (shutdown, which may happen at logoff time, must be as fast as possible as documented by MS; and timing out means we need to create a dedicated thread for the writing, and synchronizing on it (blocking), with all respective overhead for everyone). I close it NOTABUG (just because there's no suitable "COMBINATION_OF_PARTICULAR_SYSTEM_SETTINGS_AND_OUR_PROCESSING" resolution), since we have found the problem (a system configuration blocking the write on system level), and we don't have something to fix at our side for the time being. Thank you for filing the issue; and again - please do create a FAQ with your findings, which might benefit other admins. Also: please feel free to put it back to UNCONFIRMED, if you feel it should not be closed; please provide explanation why you think so, if you do.
(In reply to Mike Kaganski from comment #10) > From my times of administrating a Windows-based domain on my ex-job, I > remember struggling with RDP-related quotas, roaming profiles, and some > applications that regularly made those blow (including AutoCAD and OOo/LO). > I don't remember the RDP-related details (it was more than 7 years ago - > time flies...), but I do remember excluding some program-specific %appdata% > subfolders from roaming profile content in respective group policies (adding > exclusion of paths). Yes, the configuration of that is not straightforward. This is not exactly my case, but that for advices. In my case I don't have any RDP and also %appdata% is redirected into server by GPO. I also created a wiki page: https://wiki.documentfoundation.org/Faq/General/LibreOffice_hangs_its_process_on_window_close_and_I_can%27t_open_another_instance_(Windows) Thanks for all help. Best Regards, Michał