Bug 42673 - With disconnected network printers, Calc hangs opening some files (waiting on e.g. the Windows print spooler)
Summary: With disconnected network printers, Calc hangs opening some files (waiting on...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.4.3 release
Hardware: All All
: high major
Assignee: Not Assigned
URL: https://ask.libreoffice.org/t/calc-lo...
: 116559 132129 148238 148638 149677 150833 150979 151208 151318 151763 153962 154062 154830 (view as bug list)
Depends on:
Blocks: Network Print
  Show dependency treegraph
Reported: 2011-11-07 09:56 UTC by erikmjacobs@gmail.com
Modified: 2023-12-12 12:01 UTC (History)
26 users (show)

See Also:
Crash report or crash signature:

Example file that causes Calc to hang (45.11 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-11-07 10:09 UTC, erikmjacobs@gmail.com
soffice.bin wait chain with spoolsv.exe (11.79 KB, image/png)
2019-07-07 12:05 UTC, drakkai
WinDBG result for x86 LO 7.5+ (16.96 KB, text/plain)
2022-08-09 14:59 UTC, Timur
WinDBG dump from 64-bit (13.78 MB, application/octet-stream)
2022-08-09 15:21 UTC, Timur
181663: WinDBG dump from x86 LO 7.5+ (11.36 MB, application/octet-stream)
2022-08-10 06:51 UTC, Timur

Note You need to log in before you can comment on or make changes to this bug.
Description erikmjacobs@gmail.com 2011-11-07 09:56:40 UTC
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.
Comment 1 erikmjacobs@gmail.com 2011-11-07 10:09:09 UTC
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.
Comment 2 Markus Mohrhard 2011-11-07 11:44:27 UTC
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
Comment 3 erikmjacobs@gmail.com 2011-11-07 11:55:53 UTC
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?
Comment 4 erikmjacobs@gmail.com 2011-11-07 13:54:48 UTC
I had also run cccleaner and performed windows updates before reinstalling Libre.
Comment 5 erikmjacobs@gmail.com 2011-11-07 13:58:04 UTC
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

Attached files:

These files may be available here:

Analysis symbol: 
Rechecking for solution: 0
Report Id: 32fb2eb2-098b-11e1-a8d7-0030675a3caf
Report Status: 1
Comment 6 erikmjacobs@gmail.com 2011-11-07 15:10:35 UTC
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.
Comment 7 erikmjacobs@gmail.com 2011-11-07 15:46:51 UTC
This is on Win7 x64 Ultimate.
Comment 8 Mas 2012-09-13 10:15:07 UTC

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.
Comment 9 erikmjacobs@gmail.com 2012-09-13 13:39:25 UTC
"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?
Comment 10 Tyson Whitehead 2015-04-29 04:05:28 UTC
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


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 Build ID: c4c7d32d0d49... on Windows Vista.
Comment 11 Buovjaga 2015-10-09 18:08:08 UTC Comment hidden (obsolete)
Comment 12 Xisco Faulí 2016-09-11 19:50:04 UTC Comment hidden (obsolete)
Comment 13 Heinz Repp 2016-10-04 12:15:51 UTC
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.
Comment 14 frugal 2017-06-16 04:18:01 UTC
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.

Comment 15 frugal 2017-06-16 04:20:43 UTC
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.
Comment 16 frugal 2017-06-18 08:45:41 UTC
Also, this does NOT happen if I load an existing .xlsx file in Calc, only .ods
Comment 17 szz 2017-08-24 18:38:22 UTC
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:  \\\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)


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 x64 & WIN10 Pro
Comment 18 frugal 2017-12-16 23:22:58 UTC
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)
Comment 19 frugal 2017-12-16 23:39:00 UTC
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 .
Comment 20 frugal 2017-12-17 03:20:20 UTC
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.
Comment 21 Tim 2018-01-21 12:24:30 UTC
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
Comment 22 Jean-Baptiste Faure 2018-04-14 16:00:19 UTC
*** Bug 116559 has been marked as a duplicate of this bug. ***
Comment 23 Jean-Baptiste Faure 2019-02-04 14:23:10 UTC
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
Comment 24 drakkai 2019-07-07 12:02:56 UTC
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.
Comment 25 drakkai 2019-07-07 12:05:52 UTC
Created attachment 152615 [details]
soffice.bin wait chain with spoolsv.exe
Comment 26 Tim van der Meij 2020-01-12 21:25:34 UTC
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!
Comment 27 himajin100000 2020-08-09 12:15:26 UTC
just out of curiousity, I wonder what would happen if we do EITHER of



setting DisablePrinting in Expert configuration to true

Comment 28 krabat 2021-01-24 12:13:09 UTC
Bug is still present / reproducible in version:

Version: (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:
Comment 29 Mike Kaganski 2021-01-26 06:55:25 UTC
(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. (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
Comment 30 [REDACTED] 2021-01-27 12:50:36 UTC
Next report on ask.libreoffice.org: https://ask.libreoffice.org/en/question/289789/calc-loading-native-ods-file-is-very-slow-hanging/
Comment 31 dainius.mazuika 2021-01-27 12:59:49 UTC
Bug is still present in:

Version: (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
Comment 32 Chris Smith 2021-08-11 17:41:41 UTC
Just a me to on this. Windows 10 21H1 Libreoffice (x64). Reproducable with a network attached HP LJ Pro 148DW which is powered down and empty ODS sheet.
Comment 33 Chris Smith 2021-08-12 07:42:41 UTC
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.
Comment 34 Mike Kaganski 2021-08-12 08:00:25 UTC
(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.
Comment 35 Buovjaga 2021-08-12 08:45:00 UTC Comment hidden (obsolete)
Comment 36 Chris Smith 2021-08-12 09:55:45 UTC
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.
Comment 37 Chris Smith 2021-08-23 20:39:54 UTC
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.
Comment 38 Mike Kaganski 2021-09-03 08:35:55 UTC
(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
Comment 39 Carl Michal 2021-09-03 21:34:29 UTC
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.
Comment 40 Carl Michal 2021-09-03 23:30:05 UTC
I forgot the version: that's LO (x64)
Comment 41 NN 2022-01-23 11:55:36 UTC
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
Comment 42 Julien Nabet 2022-03-28 19:20:11 UTC
*** Bug 148238 has been marked as a duplicate of this bug. ***
Comment 43 Peter Mandrella 2022-03-29 14:15:09 UTC
As reported in 148238, the problem also occurs with LibreOffice 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.
Comment 44 Mike Kaganski 2022-04-15 07:20:13 UTC
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
Comment 45 Peter Mandrella 2022-04-15 12:36:02 UTC
I tried the workaround, and - yes, this environment setting solves the issue for me:


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.

Comment 46 Peter Mandrella 2022-04-15 12:51:14 UTC
SAL_DISABLE_DEFAULTPRINTER=1 solves the issue for Calc, Draw, Impress and Writer.

Math additionally needs SAL_DISABLE_PRINTERLIST=1.
Comment 47 Julien Nabet 2022-04-18 08:25:18 UTC
*** Bug 148638 has been marked as a duplicate of this bug. ***
Comment 48 lysathor 2022-04-19 11:32:45 UTC
I use Windows 10 x64, LibreOffice 7.3.2, Draw. It seems that I need both settings.
is not sufficient. But together with 
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.
Comment 49 Josep Blazquez 2022-05-16 12:47:46 UTC
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: (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.
Comment 50 alexandre_thib 2022-06-14 03:35:36 UTC
I am also able to repro with two different computers:

Computer #1
Windows 10 Pro
LibreOffice Calc

Computer #2
Windows 10 Pro
LibreOffice Calc

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.
Comment 51 Graham Horner 2022-07-03 12:28:13 UTC
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: (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
Comment 52 Timur 2022-08-09 14:59:28 UTC
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.
Comment 53 Mike Kaganski 2022-08-09 15:08:38 UTC
(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.
Comment 54 Mike Kaganski 2022-08-09 15:12:23 UTC
(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
Comment 55 Timur 2022-08-09 15:21:43 UTC Comment hidden (obsolete)
Comment 56 Buovjaga 2022-08-09 15:33:25 UTC Comment hidden (obsolete)
Comment 57 Mike Kaganski 2022-08-09 16:09:19 UTC Comment hidden (obsolete)
Comment 58 Buovjaga 2022-08-09 16:43:53 UTC
(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:

Comment 59 Timur 2022-08-10 06:51:25 UTC
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/.
Comment 60 Mike Kaganski 2022-08-10 07:26:52 UTC
(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.
Comment 61 Mike Kaganski 2022-08-10 08:11:57 UTC
(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.
Comment 62 Timur 2022-08-10 10:00:17 UTC
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 


- 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)
Comment 63 Timur 2022-08-11 08:31:19 UTC
*** Bug 132129 has been marked as a duplicate of this bug. ***
Comment 64 t-mor 2022-08-18 00:24:49 UTC
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.
Comment 65 Timur 2022-09-07 11:59:14 UTC
*** Bug 150833 has been marked as a duplicate of this bug. ***
Comment 66 Timur 2022-09-16 14:55:25 UTC
*** Bug 150979 has been marked as a duplicate of this bug. ***
Comment 67 Thomas Passin 2022-09-16 15:35:30 UTC
(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.
Comment 68 Timur 2022-09-29 07:20:44 UTC
*** Bug 151208 has been marked as a duplicate of this bug. ***
Comment 69 Mike Kaganski 2023-03-04 14:21:03 UTC
*** Bug 153962 has been marked as a duplicate of this bug. ***
Comment 70 Mike Kaganski 2023-04-22 08:06:13 UTC
*** Bug 154830 has been marked as a duplicate of this bug. ***
Comment 71 amoun 2023-07-13 12:23:00 UTC
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
Comment 72 Stéphane Guillou (stragu) 2023-10-24 14:23:25 UTC
*** Bug 151763 has been marked as a duplicate of this bug. ***
Comment 73 Stéphane Guillou (stragu) 2023-10-24 14:25:12 UTC
*** Bug 151318 has been marked as a duplicate of this bug. ***
Comment 74 Stéphane Guillou (stragu) 2023-11-02 22:35:22 UTC
*** Bug 154062 has been marked as a duplicate of this bug. ***
Comment 75 Stéphane Guillou (stragu) 2023-11-19 21:30:34 UTC
*** Bug 149677 has been marked as a duplicate of this bug. ***
Comment 76 Alex Hirzel 2023-12-12 12:01:08 UTC
I am able to reproduce this on Linux. Using strace(1), I can see that it hangs on a call to read(2).