Home / Couldn’t initialize printer / sumatrapdfrestrict.ini

Occurs on Server 2008R2, 2016, and 2019, but not Win10. Sumatra is set as the default pdf reader. Sumatrapdfrestrict.ini is set to allow printing, but not allow disk access. Opening a pdf and trying to print results in a “Couldn’t initialize printer” message. Simply right-clicking a file and selecting Print works fine. Happens for both local and client printers. If I change the ini file to allow disk access, printing does work; however that also gives the users access to the file system via open/save dialogs, which we can’t have.

I see that DiskAccess restricts a fair number of things. Is there a way to allow the printing function to do whatever it needs to without allowing open/save, hyperlinks, etc.?

I would swear this worked until recently; users would certainly have been complaining. I would blame it on Windows updates, but that wouldn’t explain the 2008R2 machines, nor why it still works on Win10.

May be a red herring but many print related problems (not just SumatraPDF) were caused by MS tightening the screws on 9th March see Blank Printing OR low resolution since 9th March 2021 so its worth looking/comparing at update KB numbers.

The other common UAC issue is 32 bit calling 64 or vice versa so check the caller and recipient are both working within the same bit wise workspace.

I am looking for any mix that indicates such a problem but without servers
I am not seeing issues with “local” printing using
DiskAccess = 0
PrinterAccess = 1

I am of course Admin so looking into any restricted user issues next

P.S. forgot to add ensure the ini is 8bit not 16bit
but then in that case it should not work at all

The March Win Updates were my first thought was well, as they caused us a lot of trouble. However I have exactly the same symptoms on a 2016 which did not get those updates yet, and a 2008R2 server which obviously hasn’t had any updates in a while either.

I’d swear we had tested this, but it’s possible that it was an issue for a while and this is the first time anyone complained about it.

I’m domain and local admin on these servers, and I’m seeing it as well.

Just realized there was a newer version, and upgraded from 3.1.2 to 3.2 (both 64-bit), which seems to have fixed it on one of the 2016 servers…but none of the others. I’ll give the 32-bit version a shot, thanks.

Version should not be a difference as 3.1.2 and 3.2 printing should share similar code (3.0 is different and between 3.1.2 -3.2 there was only a minor page related change) but then again the VS compilation could be a factor as XP had to be dropped.

However current 3.3 DAILY has more extra whistles and bells for page sizes so could behave different (better or worse?)

32-bit was the same. Daily build does not give the error, but when I click on print it just closes, without printing.

Thats really odd, I am not currently using latest 64bit which I presume you are as i’m testing on a 32 bit where latest release was 3.3.in August (without the extras)
so will switch back to 64bit to see if there is any reason for closure !

[Later edit] 64bit 3.3.13320 (todays build) works for me on win 10 pro fully up to-date . My default printer is a customized MS print to FILE.PDF so as to (as close as possible) emulate a virtual printer
The Physical printer is selected as required for real world testing but sending to that spools correctly, however, that then just reports it is not switched on saving the planet one sheet at a time.
With localappdata restriction in (that was wrong) non admin account (and sumatrapdf RESTRICTIONS in program files for all users) Windows had switched default to the physical printer
Thus back on win 10 attempted a print of a network “served” pdf from a remote \ \location
Again got acceptable spooling with same printer “off” as expected) SO on win 10 pro there should as observed be no problems. I cant run a 10 “home” at present to check but win 7 32 pro /64 home also seems to be ok?

The startup of SumatraPDF looks to the system default printer (which could well be stable) but on calling print dialog, it then looks to current default print driver so may respond differently especially as it was changed against my will by “Let windows manage my defaults!” . Any reason either could be in an odd state.

If the user is not opening the file then you are sending it command line ?
IF so you can also set a msgbox or similar to command line print that same filename (with page ranges if needed ?)

Yes, sending it from command line. We can and do have the option to print w/o viewing, but they also want to be able to print right from viewing the file.

It works fine on Win10 for me as well. Haven’t tried Win7, don’t have access to any at the moment and our use case is servers (all 64-bit). Seems to be only servers affected. Users are running in RDS or Citrix sessions, although RD into a Win10 still works, so not sure if it’s relevant.

My suggestion was to bypass/workaround of what appears to be a server comms issue (often seen when users include -silent into blind server CLI printing)
By most simply adding a sidekick button (would need to be “stay on top” if they are viewing fullscreen) it should be fairly easy to kill and replace button with each new file.

I agree it is a drag for each application user to provide their own fix but commercial server printing is considered “unsupported” by this basic user viewer. When working it is considered a “bonus”

You can escalate this issue to Issues · sumatrapdfreader/sumatrapdf · GitHub but it may not get resolved quickly