Recently went to open .ods files that I have never had problems with. When trying to open, calc will come up but hang and never completes opening the file. The files open fine with zip utilities as well as with LibreOffice on other OS (Linux). It appears to be this computer and not necessarily LibreOffice itself. If there are any ways to debug please let me know and I will provide additional information. I will upload a sample file shortly that suffers from this issue. Note that new files that are saved and some old files do not appear to be affected.
Created attachment 53252 [details] Example file that causes Calc to hang I have an .xls that opens fine. I saved said .xls as an .ods and tried to re-open it with Calc, and Calc hangs. This file opens fine in Calc on Linux.
try to backup your user profile, delete the existing one and thenre start calc and try to open the file again might just be a corrupted user profile dir
Where is the user profile stored in Windows 7? I attempted a complete uninstall/reinstall before I posted the bug: - Uninstall all Libreoffice - Uninstall all Visual C++ - Uninstall all Java - Remove everything I could find (Program Files (x86), Program Data/Libre Office, AppData/Roaming/Libreoffice, etc). - Reinstall The problem persisted, which is then why I posted the bug. Are there any debug modes or other logging that I can do on Windows here?
I had also run cccleaner and performed windows updates before reinstalling Libre.
Application Log: Fault bucket , type 0 Event Name: AppHangXProcB1 Response: Not available Cab Id: 0 Problem signature: P1: soffice.bin P2: 3.3.9556.500 P3: 4d061efd P4: cc55 P5: 128 P6: spoolsv.exe:spoolss P7: 0.0.0.0 P8: P9: P10: Attached files: C:\Users\Erik\AppData\Local\Temp\WER4F61.tmp.appcompat.txt C:\Users\Erik\AppData\Local\Temp\WER4FEF.tmp.WERInternalMetadata.xml These files may be available here: C:\Users\Erik\AppData\Local\Microsoft\Windows\WER\ReportArchive\AppHang_soffice.bin_382fd4bb4058dfcac8c381bbdeadb355723166b3_08c0509a Analysis symbol: Rechecking for solution: 0 Report Id: 32fb2eb2-098b-11e1-a8d7-0030675a3caf Report Status: 1
What an annoying problem. I figured out the fix. Someone on IRC suggested that spoolsv had to do with printers: 17:09 <julien2412> spoolsv.exe is a Microsoft Windows system executable which handles the printing process to your local printers. After some sleuthing, I realized that I have a network-connected printer that was offline. Apparently this makes Windows 7 *extremely* angry. After much dorking around, I was able to remove this printer. Guess what? Calc starts up just fine! This leads me to believe that there is a more sinister issue at hand. Why would .xls files and .odt files open just fine, but .ods files hang? What was it about this particular file that caused Calc to really want to get down with the printers and to hang because this printer was not connected? I will change the title of the bug.
This is on Win7 x64 Ultimate.
Hello, I am marking this ticket as resolved. The issue was resolved by you removing the printer on your network. The application have been unable to open the file due to an existing lock on the file by another application.
"The application have been unable to open the file due to an existing lock on the file by another application." Which application? Calc was the only program not able to open the file, and calc hung hard. If the file was simply locked, the expectation would be for calc to report that "this file is in use by another application." At best, this is an issue with how Calc handles file locking. At worst, this is an issue with how Calc interacts with the print stack on Windows. Saying that it's not a bug because removing the printer fixed the issue is folly. The resultant implications are that: * Temporary printer outages mean that Calc may at any moment be unusable. I guess printers never go down? * Users who travel between multiple locations (home/office, etc) and have printers in each location will have to remove and reinstall printers before leaving the previous location so that calc will work. Does this sound like it makes any sense to you?
I would add that the latest version of calc hangs for a long time and then crashes on loading an ods file unless your network printer is turned on. Took me most of the night to figure out what the heck was wrong as it was working fine earlier in the week (when the printer was on). I tried upgrading and bunch of other stuff to no avail. It wasn't until I accidentally picked print in another application that sitting there watching the pin wheel to time out triggered a memory about issues that power point has with off network printer http://www.pptfaq.com/FAQ00035_General_PowerPoint_troubleshooting_procedures.htm and made me think maybe that we my libreoffce problem too. Sure enough. I'm re-opening in hopes you will reconsider if for no other reason that libreoffice doesn't just hang but actually crashes now too. Cheers! -Tyson PS: I'm running 4.4.2.2 Build ID: c4c7d32d0d49... on Windows Vista.
Bug does not meet the criteria for Status 'REOPENED' https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/REOPENED#Criteria Status -> NEEDINFO Tyson: is this still a problem with LibO 5? Set to NEEDINFO. Change back to NEW, if the problem persists (as this is confirming an older report). Change to RESOLVED WORKSFORME, if the problem went away.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team Sun, 11 Sep 2016 21:43:24 +0200
Hello, jumping in because I have this issue with Windows 10 Pro v1607 and LibO 5.2.2. 64bit (that's why I changed Hardware from x32 to all). When opening local simple ods files, Libreoffice shows an undecorated empty and unresponsive window for about one minute. Digging with sysinternals Process Monitor, I see it continuing right after having loaded the printer spooler dll (ps5ui.dll), having dealt with printers when starting to be unresponsive. I have network printers not connected at this moment, that use the Postscript interface, so I guess Libreoffice hangs waiting for Windows loading the spooler ui dll, but that is clearly not the intended behavior. I would expect to load the spooler dll from a non blocking thread while proceeding to open the file would solve this issue - showing an empty hanging windows to the user should never happen.
I am having the same issue with LibreOffice_5.2.7_Win_x86 under Windows 8 x64. When I load a file in Calc, it hangs for up to 2 minutes with the windows "Loading wheel icon" and becomes completely unresponsive. Afterwards it works as normal. My main printer is a network printer that is usually offline. No issues if the printer is online. Here is someone else with the same issue - Like them, If I stop the windows process splwow64.exe as Calc is being unresponsive, calc resumes instantly (it becomes responsive) - Or, if I do "ipconfig /release" while Calc is being unrespnsive, it instantly becomes responsive. https://ask.libreoffice.org/en/question/18138/calc-hangs-on-opening-ods-file-seems-related-to-printer-availability/
To be clear, loading any Calc file in Calc causes this, not a specific file. Also, this freezing does not seem to happen if I load Libreoffice and click CREATE - Calc Spreadsheet. Only loading an existing file.
Also, this does NOT happen if I load an existing .xlsx file in Calc, only .ods
I could fix an ods whcih hangs when network printer was unavailable. There is a section in ods (renamed to zip and extract settings.xml file from it) where the printer related option stored. My netowork printer adreess was: \\192.168.1.11\lp If I delete printer related data section from settings.xml ods file opens like a charm even the network printer is unavailable :) So delete XML data tags: PrinterName and PrinterSetup (whole xml data tags) (of course make a backup from ods 1st) <config:config-item config:name="PrinterName" config:type="string">\\192.168.1.11\lp</config:config-item><config:config-item config:name="PrinterSetup" config:type="base64Binary">ZQX+/1cvfgsdhdfzjdtzjdtzjdtzjfzhukgijhlAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbbbbbbbbbAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAARXBzb24gRVNDL1AtUiBWNCBDbGFzcyBEcffffffffffffffffffffffffAAEAAhSAAAEdAAAM1ROVwAAAAAKAFwAXAAxADkAMgAuAfafasdffasdfalésfdAs,dfÉSAD,fgksdmfgasmdfgsdfgsdaaaaaaaaaaaaaaaaaaBAMG3AfgsdfgsdfgsdfgsdfgsdfgsdfgsdfgsdfgsdfgfffffffffffffffffffffffAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAQAAAAIAAAABAAAA/////0dJfgQAAAAAAAAAAAAAAAsdfgsdffffffffffffffffffffffffffffffffffAAAAAAAAAAAAAAAAAAAAkAAAAAAAAAAAAAAAEAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsdfgAAAAAAAAdsfgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsdfgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAsdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAdfgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAfgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddgggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggggsdfgg==</config:config-item> In My case the printer was an usb printer connected to my NAS and it was used by some Windows machines on home network. When the NAS was turned off (or its LAN cable unplugged) ods files freezed at opening. In Calc File/Printer settings without deletion I could see the old network printer IP, after deletion there I could see my current default printer (also a network printer but connected to my router) however the settings.xml did not have the deleted tags. So the final fix should be using some timeout at opening or a popup window about unavailable network printer and an option to delete old printer info from ods. LO version 5.3.4.2 x64 & WIN10 Pro
I wanted to add that this freezing can happen with an opened document that I'm editing, when I do certain tasks like highlight data and Ctrl-Rightclick-Format cells. Sometimes (not always) that action can freeze for 30 seconds before the Format cells dialog comes up. Again this won't happen if my network printer is ONLINE only when it is OFFLINE. szz, I tried your trick but it did not work for me. (Although I do see mentions of an offline printer in many of my .ods files)
szz, actually I think I spoke too soon. I think you're right. If I set my default printer to the "windows XPS writer" and create a new .ods, that file loads fine and has no issues. Only the files I created when my network printer was default have freezing issues .
a partial fix: Load the file, pick File-> Printer Settings and select "Microsoft XPS Document Writer" or some other non-network printer, then re-save the file. however there is still some freezing if your windows default printer is set to a offline network printer, despite doing the above. But it helps somewhat.
Calc hang on open any ods files until I cleared print queue and completely removed virtual printer (ImagePrinter) from OS. The queue appeared from some bug in that printer during printing a .pdf file into images by other software (not LO). Win7 x32 Calc 5.2.7.2
*** Bug 116559 has been marked as a duplicate of this bug. ***
I have the same problem under Linux (Ubuntu 16.04 x86-64) with LO 6.1.4 and network printers not reachable. If I disconnect my PC from the network, Calc opens the file instantly. Best regards. JBF
I have the same problem on Windows 10 (version 1903 and 1809). When network printer is disconnected Calc hangs opening any files, I've tried couple version 6.2.x, 6.1.x and 6.0.x.
Created attachment 152615 [details] soffice.bin wait chain with spoolsv.exe
I also encountered this problem today and it took a long time to find the root cause. I have some additional details to share. I did a clean install of Windows and found that LibreOffice Calc would take 13 seconds to open even the most basic ODS files while this didn't happen before. XLSX files worked just fine. I tried everything from reinstalling LibreOffice to removing the profile directory with no result. I finally reinstalled Windows again and kept track of when LibreOffice Calc would stop working. I found that it started occurring when I installed the printer (Epson XP 630) through Windows and the printer was offline, and found this bug. Like others noticed above, ODS files (for most likely a good reason) contain a reference to the printer, so I presume LibreOffice Calc is trying to locate this printer upon startup. Unticking the "Load printer settings with the document" as suggested in https://bugs.documentfoundation.org/show_bug.cgi?id=116559 did not work for me, but what did work was changing the default printer to e.g., the Microsoft XPS Writer. I looked into this and found that Windows installed the default Microsoft IPP drivers for the printer instead of the Epson drivers, and I can only assume that the spooler keeps on trying to connect to the printer even though it's offline. The moment I installed the Epson-specific drivers, the problem was gone. I guess it has a faster way to tell the spooler that the printer cannot be reached. I would say that Windows is at fault for not installing the Epson drivers by default and for having a default driver that apparently makes the spooler wait for a long time before reporting that the printer is offline. However, I agree with Comment 13 that LibreOffice Calc can mitigate the issue by querying the spooler in a separate thread. Removing the spooler actions from the main thread would allow the rest of LibreOffice Calc to work correctly and the document to open normally, while in the background the spooler is queried. This would make the issue invisible for the user because having to wait 10+ seconds for a document to open is too long. I'm hoping this will help to get the issue resolved. Thank you for all your work on LibreOffice!
just out of curiousity, I wonder what would happen if we do EITHER of 1. setting "SAL_DISABLE_DEFAULTPRINTER" https://opengrok.libreoffice.org/xref/core/vcl/source/gdi/print.cxx?r=750a6bdd#439 2. setting DisablePrinting in Expert configuration to true https://opengrok.libreoffice.org/xref/core/sfx2/source/view/viewsh.cxx?r=2b196f3b#694
Bug is still present / reproducible in version: Version: 7.0.4.2 (x64) Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 16; OS: Windows 10.0 Build 19042; UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL Issue documented: https://ask.libreoffice.org/en/question/289171/how-can-i-improvedebug-libreoffices-startup-times/
(In reply to Tim van der Meij from comment #26) > I found that it started occurring when I installed the printer > (Epson XP 630) through Windows and the printer was offline, and found this > bug. This promised to be helpful to reproduce the problem. However, I still was unable to repro. What I did: 1. I went to Epson web site [1], chose "Windows 10 (64-bit)" to download "Drivers and Utilities Combo Package Installer" (XP630_Lite_NA.exe from 2019-05-20, 11.9 MB) 2. I started the installer, and allowed it to install "drivers and utilities" only (and allowed Windows Firewall) 3. I didn't configure printer there in the installer (I don't have one) 4. I opened Windows 10 Start Manu->Settings->Devices->Printers and Scanners 5. [+] Add a printer or scanner -> The printer that I want isn't listed 6. Add a printer using a TCP/IP address or hostname 7. Device type: TCP/IP Device; Hostname or IP address: e.g. 192.168.1.100 (a random unused IP in my subnet); "[ ] Query the printer ..." unchecked 8. Device Type: Standard -> EPSON Network Printer 9. I chose Epson XP 630 model in the list 10. Clicked Next and checked "[x] Set as the default printer", and finished Starting Calc (either from the start center, or using dedicated Start Menu shortcut (soffice --calc)) still does not give a timeout problem here. If someone could provide detailed steps to follow to have the problem appear, please provide them very verbosely, so that one could be sure one uses the known problematic configuration. There are many variables on each step, as I shown above. Which driver for which model, architecture and which version to use? How to install? which networking settings to configure? ... Knowing these could allow a developer to see and fix this. Thanks! [1] https://epson.com/Support/Printers/All-In-Ones/XP-Series/Epson-XP-630/s/SPT_C11CE79201
Next report on ask.libreoffice.org: https://ask.libreoffice.org/en/question/289789/calc-loading-native-ods-file-is-very-slow-hanging/
Bug is still present in: Version: 7.1.0.2 (x64) / LibreOffice Community Build ID: 53d68d29d90fd16448721a60aad68c28ff0809f5 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Just a me to on this. Windows 10 21H1 Libreoffice 7.0.6.2 (x64). Reproducable with a network attached HP LJ Pro 148DW which is powered down and empty ODS sheet.
After arguing with this for a couple of hours, I resolved the issue by replacing the HP M148DW driver that was provided by Windows Update with the driver from HP's web site. This appears to have solved the issue entirely. There has been no other changes to the system or print configuration or defaulting apart from that.
(In reply to Chris Smith from comment #33) But what was the exact name and version of the *problematic* driver? I try to install the driver on a system without such a printer (in the hope that absent printer fits the "disconnected" state), but fail to see a match in the list shown by MS "Add Printer" wizard. Please note that I already asked for this info at comment 29; people seem to struggle, ask, provide workarounds, but ignore the request that is intended to help *resolving* the issue.
(In reply to Mike Kaganski from comment #34) > (In reply to Chris Smith from comment #33) > > But what was the exact name and version of the *problematic* driver? I try > to install the driver on a system without such a printer (in the hope that > absent printer fits the "disconnected" state), but fail to see a match in > the list shown by MS "Add Printer" wizard. Please note that I already asked > for this info at comment 29; people seem to struggle, ask, provide > workarounds, but ignore the request that is intended to help *resolving* the > issue. Pinging Chris
Not sure if you'll be able to repro it with the HP drivers without a printer as the installer is pretty abhorrently implemented and tries to wrangle you to go through a wizard to install the driver. However there is an interesting disparity. The original driver install uses IPP as the printer driver as ID'ed from c:\windows\inf\setupapi.dev.log. The installed INF was from prnms012.inf:5911414ecf032fb9:MS_IPP:10.0.19041.1:1284_cid_ms_ipp The new working driver is an official HP LaserJet Pro M148-M149 PCL-6 driver from here: https://ftp.hp.com/pub/softlib/software13/printers/LJ/LJM148M149_UWWL_3-1_Basicx64_44.5.2694.exe which does not use IPP. Ergo this issue may be caused by default IPP drivers. Let me know if you need any further info as I have a reasonable forensic trail here.
Another accidental discovery today. The issue also occurs if you have an IPP connected printer on a client, RDP into a remote server (with printing enabled on the RDP connection) and open a calc document. If you install the full driver pack on the client, the remote server Libreoffice does not hang on document load.
(In reply to Chris Smith from comment #36) > Not sure if you'll be able to repro it with the HP drivers without a printer > as the installer is pretty abhorrently implemented and tries to wrangle you > to go through a wizard to install the driver. It seems that you are correct; I am still unable to repro. Could someone who is able to reproduce this, use one of the methods to generate a minidump from the "hung" process [1] [2], and attach it here? It would allow to open the dump in a debugger, and maybe see the call stack that could allow to suggest a blind fix. [1] https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#Windows [2] https://docs.microsoft.com/en-us/sysinternals/downloads/procdump
I think I see a problem that is the same as what's described here. Libreoffice was taking forever to load documents. If started without a document to open, it would start normally, but then when a document was opened it would hang for 60 seconds or more. Afterwards it would run ok, except sometimes would again hang for a minute or two. I noticed that it didn't happen if there was no network connection. I finally found this report and it connected the dots for me. I recently set up a printer with microsoft's built-in 'Save to PDF' driver, that spools to a linux cups server. Today I'm on a network now where that cups server is unreachable. My printer was configured via: "Select a shared printer by name" with an address of the form: http://server.ip.add.ress:631/printers/queue_name Seems like that should be straightforward to reproduce. As soon as I deleted that printer queue, the problem is gone.
I forgot the version: that's LO 7.2.0.4 (x64)
I can confirm Carl Michal’s observations. I had the same issue on Win10 with LO 7.1.8, 7.2.5 and 7.3.0. Opening an .ods takes 20+ seconds when my cups-server is offline. It works fine in each of these cases: 1) no network connection 2) MS "save to pdf" as standard printer and "load printer settings with the document" deactivated 3) cups-server is online
*** Bug 148238 has been marked as a duplicate of this bug. ***
As reported in 148238, the problem also occurs with LibreOffice 7.2.6.2 on Windows 11. Some more details on that: - happens with all of LO Write, Calc, Draw, Math and Impress - happens also with Pegasus Mail, so it's not specific to LibreOffice - happens when opening an existing document or just starting the App with a blank document - hangs ~60 seconds for each unavailable network printer - hangs directly on app start, showing the App window frame with just grey epmty space inside - happens only shortly after booting Windows, and only once after each boot - ends hanging immediately when disconnecting the network - ends hanging immediately when reconnecting the network printer. This points to some Windows API function that is blocking after Windows startup until the OS has given up on contacting the network printers. If someone commits to trying a fix, I can provide dumps as requested in comment #38 per Email. Don't want to publish them here for privacy and security reasons.
Possible code pointers: For Calc, there is ScDocumentConfiguration::setPropertyValue [1], called when loading ODS (other modules might have similar code). It has several cases that call pDocShell->GetPrinter and pDocShell->SetPrinter. The calls may create both system-default printers, and/or printers defined in the document properties (so the problems experienced may depend both on system-default, and non-default printers). The code that makes system calls is, in Windows case, in vcl/win/gdi/salprn.cxx (e.g., WinSalInstance::GetDefaultPrinter calls GetDefaultPrinterW [2], which is documented to possibly block). But that low-level WinSalInstance code is called from Printer class [3], and it is subject to some environment variables (SAL_DISABLE_DEFAULTPRINTER and SAL_DISABLE_PRINTERLIST; see calls to 'getenv') - defining those variables might possibly help workaround the problem. The possible fix could be delay-loading the printer data, only storing the information for initialization in ScDocumentConfiguration::setPropertyValue for a future use, when it is really needed by other code (like display of page breaks). Another possibility would be moving the initialization into separate threads - but that would be likely difficult, given that there might be several printer-related properties in the document, and then asynchronous setting of one of those would still block when another one needs to be set, and thus needs to wait for the first one to finish. [1] https://opengrok.libreoffice.org/xref/core/sc/source/ui/unoobj/confuno.cxx?r=88d8c9af&mo=6051&fi=134#134 [2] https://docs.microsoft.com/en-us/windows/win32/printdocs/getdefaultprinter [3] https://opengrok.libreoffice.org/xref/core/vcl/source/gdi/print.cxx?r=14b21954#442
I tried the workaround, and - yes, this environment setting solves the issue for me: SAL_DISABLE_DEFAULTPRINTER=1 LibreOffice apps do no longer hang on startup, but only when I actually try to print a document. And before each print, the message "No default printer found" (translated from German by me) must be confirmed, and a printer must be selected. Then, I alternatively tried to set the default printer in the Windows control printer to a local printer (the Print-to-PDF device included with Windows 11). That did not work for LibreOffice, but for Pegasus Mail. Nice, now all fine. Thanks!
SAL_DISABLE_DEFAULTPRINTER=1 solves the issue for Calc, Draw, Impress and Writer. Math additionally needs SAL_DISABLE_PRINTERLIST=1.
*** Bug 148638 has been marked as a duplicate of this bug. ***
I use Windows 10 x64, LibreOffice 7.3.2, Draw. It seems that I need both settings. SAL_DISABLE_DEFAULTPRINTER=1 is not sufficient. But together with SAL_DISABLE_PRINTERLIST=1 I could open my document again. Please try to fix that issue as realizing that such a workaround is necessary and available usually is beyond a normal experienced user who only sees that he/she cannot open an old document.
I'm able to reproduce this at will with my wifi printer Brother DCP-J572DW (not attached to anything, Windows 10, Brother supplied drivers, Default printer) Version: 7.2.5.2 (x64) / LibreOffice Community Build ID: 499f9727c189e6ef3471021d6132d4c694f357e5 CPU threads: 16; OS: Windows 10.0 Build 19044; UI render: default; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL If its powered off I have around 10-30 secs delay when opening a trivial test document. When I power it, it takes 1-2 sec to open the document. If I disable the "load printer configuration" option, it takes <1 sec. Let me know if I can help.
I am also able to repro with two different computers: Computer #1 Windows 10 Pro 10.0.19043 LibreOffice Calc 7.2.4.1 Computer #2 Windows 10 Pro 10.0.19044 LibreOffice Calc 7.3.2.2 The printer is a MFC-L3770CDW. When it was powered off, the file would take so long to load that we killed the app and though the file was corrupted. But we realized that new files were affected as well. At some point we left it longer (~30 seconds) and it finally loaded. Turning on the printer "fixed" this issue.
Just a me too with how I fixed it. New Windows 11 installation. Windows automatically found my Brother DCP-J4120DW on the LAN (WiFi) and installed it with IPP. Calc slow to load but second Calc loads fine and Writer loads fine. After reading through this I realised I couldn't even print a test page so the driver wasn't working. Downloaded the complete Brother bloatware - installed that and deleted the printer Windows had installed. Works. Calc even starts up quickly if I turn the printer off. Version: 7.3.4.2 (x64) / LibreOffice Community Build ID: 728fec16bd5f605073805c3c9e7c4212a0120dc5 CPU threads: 12; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-US Calc: threaded
Created attachment 181660 [details] WinDBG result for x86 LO 7.5+ I had a variant of this bug with LO 7.2 and 7.5+. Not that fileopen was slow, but file I used recently would just crash LO. 64-bit doesn't indicate why, 32-bit mentions print driver host. Workaround was to extract ODS, remove printer info and pack it again. And that file can be open on another computer, it's not about LO version. As Comment 38 explained, repro steps or dump are needed. Here is a result from WinDBG for x86 LO 7.5+. Mike, I hope you will see this. I can upload .dmp if needed.
(In reply to Timur from comment #52) > I can upload .dmp if needed. Yes please! The call stack has some unclear portions (esp. "ScChart2DataProvider::removeVetoableChangeListener", which is the most interesting frame, that is reported wrong). I hope that .dmp could clarify that.
(In reply to Mike Kaganski from comment #53) Also: please use some released version - e.g., the 7.2 that you mentioned. Unfortunately, for 7.5 dailies, we would likely not have debug symbols, so I wouldn't be able to make sense of the .dmp
Created attachment 181663 [details] WinDBG dump from 7.4.0.1 64-bit Here is WinDBG dump from 7.4.0.1 64-bit, I hope it will work.
(In reply to Mike Kaganski from comment #54) > (In reply to Mike Kaganski from comment #53) > > Also: please use some released version - e.g., the 7.2 that you mentioned. > Unfortunately, for 7.5 dailies, we would likely not have debug symbols, so I > wouldn't be able to make sense of the .dmp Win-x86@39 should have symbols.
(In reply to Timur from comment #55) > Here is WinDBG dump from 7.4.0.1 64-bit, I hope it will work. No, it seems that there's no 7.4.0.1 symbols (it's not a released version, maybe that's why; or maybe not uploaded to the server yet). (In reply to Buovjaga from comment #56) > Win-x86@39 should have symbols. That's great info! So likely both 7.2, and a Win-x86@39 daily, would do (I assume, the symbols are updated together with the package, so we'd need a current daily, right?)
(In reply to Mike Kaganski from comment #57) > (In reply to Buovjaga from comment #56) > > Win-x86@39 should have symbols. > > That's great info! So likely both 7.2, and a Win-x86@39 daily, would do (I > assume, the symbols are updated together with the package, so we'd need a > current daily, right?) Maybe the symbols are kept for a handful of builds, not sure. Anyway, from https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg#First_Time_Setup have for symbol path: CACHE*C:\symbols;SRV*https://dev-builds.libreoffice.org/daily/master/Win-x86@39/symbols;SRV*http://dev-downloads.libreoffice.org/symstore/symbols;SRV*http://msdl.microsoft.com/download/symbols
Created attachment 181675 [details] 181663: WinDBG dump from x86 LO 7.5+ Here is x86 master. That's why I used it, it has https://dev-builds.libreoffice.org/daily/master/Win-x86@39/symbols/.
(In reply to Timur from comment #59) > Created attachment 181675 [details] > 181663: WinDBG dump from x86 LO 7.5+ FTR: it is using a build from 2022-08-08_00.08.14. Thanks! Looking.
(In reply to Timur from comment #52) > I had a variant of this bug with LO 7.2 and 7.5+. Not that fileopen was > slow, but file I used recently would just crash LO. > 64-bit doesn't indicate why, 32-bit mentions print driver host. > Workaround was to extract ODS, remove printer info and pack it again. > And that file can be open on another computer, it's not about LO version. The call stack from attachment 181675 [details]: > gdi32.dll!_NtGdiOpenDCW@32() Unknown > gdi32.dll!_bCreateDCW@20() Unknown > gdi32.dll!_CreateICW@16() Unknown > vclplug_winlo.dll!ImplCreateICW_WithCatch(wchar_t * pDriver, const wchar_t * pDevice, const _devicemodeW * pDevMode) Line 980 C++ > vclplug_winlo.dll!ImplCreateSalPrnIC(const WinSalInfoPrinter * pPrinter, const ImplJobSetup * pSetupData) Line 1003 C++ > vclplug_winlo.dll!WinSalInstance::CreateInfoPrinter(SalPrinterQueueInfo * pQueueInfo, ImplJobSetup * pSetupData) Line 1041 C++ > mergedlo.dll!Printer::ImplInit(SalPrinterQueueInfo * pInfo) Line 650 C++ > mergedlo.dll!Printer::Printer(const rtl::OUString & rPrinterName) Line 900 C++ > mergedlo.dll!SfxPrinter::SfxPrinter(std::unique_ptr<SfxItemSet,std::default_delete<SfxItemSet>> && pTheOptions, const JobSetup & rTheOrigJobSetup) Line 82 C++ > [Inline Frame] mergedlo.dll!VclPtr<SfxPrinter>::Create(std::unique_ptr<SfxItemSet,std::default_delete<SfxItemSet>> &&) Line 129 C++ > mergedlo.dll!SfxPrinter::Create(SvStream & rStream, std::unique_ptr<SfxItemSet,std::default_delete<SfxItemSet>> && pOptions) Line 50 C++ > sclo.dll!ScDocumentConfiguration::setPropertyValue(const rtl::OUString & aPropertyName, const com::sun::star::uno::Any & aValue) Line 253 C++ > mergedlo.dll!SvXMLUnitConverter::convertPropertySet(const com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> & rProperties, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aProps) Line 812 C++ > sclo.dll!ScXMLImport::SetConfigurationSettings(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & aConfigProps) Line 795 C++ > mergedlo.dll!XMLDocumentSettingsContext::endFastElement(long __formal) Line 342 C++ > mergedlo.dll!SvXMLImport::endFastElement(long Element) Line 870 C++ > expwraplo.dll!`anonymous namespace'::Entity::endElement() Line 515 C++ > expwraplo.dll!sax_fastparser::FastSaxParserImpl::consume(`anonymous-namespace'::EventList & rEventList) Line 1030 C++ > expwraplo.dll!sax_fastparser::FastSaxParserImpl::parseStream(const com::sun::star::xml::sax::InputSource & rStructSource) Line 869 C++ > expwraplo.dll!sax_fastparser::FastSaxParser::parseStream(const com::sun::star::xml::sax::InputSource & aInputSource) Line 1484 C++ > mergedlo.dll!SvXMLImport::parseStream(const com::sun::star::xml::sax::InputSource & aInputSource) Line 514 C++ > sclo.dll!ScXMLImportWrapper::ImportFromComponent(const com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> & xContext, const com::sun::star::uno::Reference<com::sun::star::frame::XModel> & xModel, com::sun::star::xml::sax::InputSource & aParserInput, const rtl::OUString & sComponentName, const rtl::OUString & sDocName, const com::sun::star::uno::Sequence<com::sun::star::uno::Any> & aArgs, bool bMustBeSuccessful) Line 185 C++ > sclo.dll!ScXMLImportWrapper::Import(ImportFlags nMode, ErrCode & rError) Line 465 C++ > [Inline Frame] sclo.dll!ErrCode::operator bool() Line 84 C++ > sclo.dll!ScDocShell::LoadXML(SfxMedium * pLoadMedium, const com::sun::star::uno::Reference<com::sun::star::embed::XStorage> & xStor) Line 494 C++ > sclo.dll!ScDocShell::Load(SfxMedium & rMedium) Line 624 C++ > mergedlo.dll!SfxObjectShell::LoadOwnFormat(SfxMedium & rMedium) Line 3181 C++ > mergedlo.dll!SfxObjectShell::DoLoad(SfxMedium * pMed) Line 680 C++ > mergedlo.dll!SfxBaseModel::load(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & seqArguments) Line 1931 C++ > mergedlo.dll!`anonymous namespace'::SfxFrameLoader_Impl::load(const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & rArgs, const com::sun::star::uno::Reference<com::sun::star::frame::XFrame> & _rTargetFrame) Line 725 C++ > mergedlo.dll!framework::LoadEnv::impl_loadContent() Line 1159 C++ > mergedlo.dll!framework::LoadEnv::start() Line 399 C++ > mergedlo.dll!framework::LoadEnv::startLoading(const rtl::OUString & sURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lMediaDescriptor, const com::sun::star::uno::Reference<com::sun::star::frame::XFrame> & xBaseFrame, const rtl::OUString & sTarget, long nSearchFlags, LoadEnvFeatures eFeature) Line 301 C++ > mergedlo.dll!framework::LoadDispatcher::impl_dispatch(const com::sun::star::util::URL & rURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lArguments, const com::sun::star::uno::Reference<com::sun::star::frame::XDispatchResultListener> & xListener) Line 108 C++ > mergedlo.dll!framework::LoadDispatcher::dispatchWithReturnValue(const com::sun::star::util::URL & rURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lArguments) Line 60 C++ > mergedlo.dll!comphelper::SynchronousDispatch::dispatch(const com::sun::star::uno::Reference<com::sun::star::uno::XInterface> & xStartPoint, const rtl::OUString & sURL, const rtl::OUString & sTarget, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & lArguments) Line 62 C++ > mergedlo.dll!SfxApplication::OpenDocExec_Impl(SfxRequest & rReq) Line 1069 C++ > mergedlo.dll!SfxStubSfxApplicationOpenDocExec_Impl(SfxShell * pShell, SfxRequest & rReq) Line 1280 C++ > mergedlo.dll!SfxDispatcher::Call_Impl(SfxShell & rShell, const SfxSlot & rSlot, SfxRequest & rReq, bool bRecord) Line 254 C++ > mergedlo.dll!SfxDispatcher::Execute_(SfxShell & rShell, const SfxSlot & rSlot, SfxRequest & rReq, SfxCallMode eCallMode) Line 754 C++ > mergedlo.dll!SfxDispatcher::Execute(unsigned short nSlot, SfxCallMode eCall, const SfxItemSet & rArgs) Line 898 C++ > mergedlo.dll!SfxApplication::OpenDocExec_Impl(SfxRequest & rReq) Line 723 C++ > mergedlo.dll!SfxStubSfxApplicationOpenDocExec_Impl(SfxShell * pShell, SfxRequest & rReq) Line 1280 C++ > mergedlo.dll!SfxDispatcher::Call_Impl(SfxShell & rShell, const SfxSlot & rSlot, SfxRequest & rReq, bool bRecord) Line 254 C++ > mergedlo.dll!SfxDispatcher::PostMsgHandler(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest>> pReq) Line 992 C++ > [Inline Frame] mergedlo.dll!std::invoke(void(SfxDispatcher::*)(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest>>) &) Line 1540 C++ > [Inline Frame] mergedlo.dll!std::_Invoker_ret<std::_Unforced,0>::_Call(void(SfxDispatcher::*)(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest>>) &) Line 670 C++ > [Inline Frame] mergedlo.dll!std::_Call_binder(std::_Invoker_ret<std::_Unforced,0>) Line 1307 C++ > [Inline Frame] mergedlo.dll!std::_Binder<std::_Unforced,void (__thiscall SfxDispatcher::*)(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest>>),SfxDispatcher *,std::_Ph<1> const &>::operator()(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest>> &&) Line 1344 C++ > [Inline Frame] mergedlo.dll!std::invoke(std::_Binder<std::_Unforced,void (__thiscall SfxDispatcher::*)(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest>>),SfxDispatcher *,std::_Ph<1> const &> &) Line 1534 C++ > [Inline Frame] mergedlo.dll!std::_Invoker_ret<void,1>::_Call(std::_Binder<std::_Unforced,void (__thiscall SfxDispatcher::*)(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest>>),SfxDispatcher *,std::_Ph<1> const &> &) Line 651 C++ > mergedlo.dll!std::_Func_impl_no_alloc<std::_Binder<std::_Unforced,void (__thiscall SfxDispatcher::*)(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest>>),SfxDispatcher *,std::_Ph<1> const &>,void,std::unique_ptr<SfxRequest,std::default_delete<SfxRequest>>>::_Do_call(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest>> && <_Args_0>) Line 823 C++ > [Inline Frame] mergedlo.dll!std::_Func_class<void,std::unique_ptr<SfxRequest,std::default_delete<SfxRequest>>>::operator()(std::unique_ptr<SfxRequest,std::default_delete<SfxRequest>>) Line 869 C++ > [Inline Frame] mergedlo.dll!SfxHintPoster::DoEvent_Impl(void *) Line 43 C++ > mergedlo.dll!SfxHintPoster::LinkStubDoEvent_Impl(void * instance, void * data) Line 39 C++ > [Inline Frame] mergedlo.dll!Link<void *,void>::Call(void *) Line 111 C++ > [Inline Frame] mergedlo.dll!ImplHandleUserEvent(ImplSVEvent *) Line 2229 C++ > mergedlo.dll!ImplWindowFrameProc(vcl::Window * _pWindow, SalEvent nEvent, const void * pEvent) Line 2799 C++ > mergedlo.dll!SalFrame::CallCallback(SalEvent nEvent, const void * pEvent) Line 306 C++ > [Inline Frame] vclplug_winlo.dll!ImplHandleUserEvent(HWND__ *) Line 4159 C++ > vclplug_winlo.dll!SalFrameWndProc(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam, bool & rDef) Line 5810 C++ > vclplug_winlo.dll!SalFrameWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned int wParam, long lParam) Line 5918 C++ > user32.dll!_InternalCallWinProc@20() Unknown > user32.dll!_UserCallWinProcCheckWow@32() Unknown > user32.dll!_DispatchMessageWorker@8() Unknown > user32.dll!_DispatchMessageW@4() Unknown > [Inline Frame] vclplug_winlo.dll!ImplSalDispatchMessage(const tagMSG *) Line 475 C++ > vclplug_winlo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 506 C++ > vclplug_winlo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 581 C++ > [Inline Frame] mergedlo.dll!ImplYield(bool) Line 475 C++ > mergedlo.dll!Application::Yield() Line 559 C++ > mergedlo.dll!Application::Execute() Line 453 C++ > mergedlo.dll!desktop::Desktop::Main() Line 1606 C++ > mergedlo.dll!ImplSVMain() Line 203 C++ > [Inline Frame] mergedlo.dll!SVMain() Line 235 C++ > mergedlo.dll!soffice_main() Line 94 C++ It indicates that code pointer in comment 44 is correct (at least for this crash). However, delay-loading would not avoid the crash itself - it needs a separate investigation.
This was Low but really is Medium or High with crashes. Average user will hardly detect a cause. Bug 139013 is probably a duplicate. Let me summarize workarounds (depending if file can be opened): - remove offline/disconnected network printer from the system - extract ODS fle, edit settings.xml to remove whole XML data tags: PrinterName and PrinterSetup, zip again and rename it back to ODS - start LO with env. variables: SAL_DISABLE_DEFAULTPRINTER=1 and SAL_DISABLE_PRINTERLIST=1 - uncheck Tools > Options > Load/Save > General > [] Load printer settings with the document (it will not remove printer info from the file but printer can be changed) - File > Properties > General > Reset Properties (it will not remove printer section from the file but can replace it with the new default one)
*** Bug 132129 has been marked as a duplicate of this bug. ***
@Timur First of all thanks for finding the duplicate. Uninstalling the printer as workaround? But only if you never use it again. A typical use case is a notebook, which is sometimes in the network of the printer and sometimes not. Manipulate the ods-files as workaround? Not really. IMHO ... then a better workaround would be to use MS Office... you could still print, don't have to manipulate files and don't have all these troubles in the M$ world. ;) ;) Since the problem is related to the spooler service, the easiest workaround is to start/stop the spooler service. An option is to write a small script that switches off the spooler service as soon as you're on the go. You could check the printer status via Powershell or cmd to see if the service has to be started or stopped. If necessary, you could call the script when you log in. So it becomes bearable in the end, but of course ... nothing more.
*** Bug 150833 has been marked as a duplicate of this bug. ***
*** Bug 150979 has been marked as a duplicate of this bug. ***
(In reply to Timur from comment #66) > *** Bug 150979 has been marked as a duplicate of this bug. *** Thanks for finding the original bug, which I was not able to do. I tried the suggestion from comment 62: "uncheck Tools > Options > Load/Save > General > [] Load printer settings with the document (it will not remove printer info from the file but printer can be changed)" This did not change the behavior, whether the network printer was turned on or off.
*** Bug 151208 has been marked as a duplicate of this bug. ***
*** Bug 153962 has been marked as a duplicate of this bug. ***
*** Bug 154830 has been marked as a duplicate of this bug. ***
Window 11, Epson ET3850 After reading the previous * In Win11: Removing the ET3850 as the default printer stopped the delay in opening ods files. * In Win11: Driver was set to [Microsoft IPP Class Driver] Selecting [Epson ESC/P-R V4 Class Driver] Solved the issue and the ET3850 can now be set as the default printer
*** Bug 151763 has been marked as a duplicate of this bug. ***
*** Bug 151318 has been marked as a duplicate of this bug. ***
*** Bug 154062 has been marked as a duplicate of this bug. ***
*** Bug 149677 has been marked as a duplicate of this bug. ***
I am able to reproduce this on Linux. Using strace(1), I can see that it hangs on a call to read(2).