Fixing Print Spooler Crashes - improving print spooler stability

A few times a month PaperCut users email us with print queue/spooler stability issues. Although the issues in most cases do not related to PaperCut, it’s a common topic among many large sites. This Knowledge Base article discusses print spooler issues and suggests a few changes we’ve found effective as a result of our work over the past 10 years working in sites with very high volume print environments.

Print queue stability issues may manifest in a few different ways:

  • The print queues randomly lock up from time to time. A problem job needs to be cleared.
  • The print queues randomly lock up from time to time. Any problem jobs can’t be cleared!
  • The print spooler service (spoolsv.exe) crashes. Errors reported in Windows Event Monitor.
  • The print spooler service hangs or live-locks taking down all queues.

The behavior is usually random or many correlated with high print/server load. In same cases it may relate to events such as printing a particular type of print job.

Over the years many we’ve worked with a number of PaperCut users to isolate these types of issues. In almost all cases they have been isolated to driver related issues or bugs. (Usually this has been done by painstakingly removing one printer or driver type at a time until the problem is isolated!)

General Discussion

Most print spooler crashes are caused by bad drivers (driver bugs). Unlike other print queue architectures (like CUPS on Linux), the Windows print spooler system is monolithic - It works as a single process and loads driver code into the spooler process’ address space. This means that driver code crash will not only bring down the current job, but also the spooler or queue as a whole affecting all printers.

How can you tell which print driver is causing the trouble? In a separate article with describe how to track down problematic print drivers. If you can track down which driver is causing the trouble, then you might be able to replace it with a different one (there are tens of thousands of print drivers out there) or you can try making some of the configuration changes described below to prevent issues from occurring or limit the impact.

Local Rendering Only

The majority of the code in the driver is responsible for rendering/rasterizing the job into languages such as PCL, Postscript, etc. Hence by definition this is likely to be the area where most bugs exist. The task of rendering can be moved from the server to the workstations by turning off an option called Advanced Printing Features. Back in Windows NT this option was called “Always spool in RAW” (and the backing registry key still has this name). Today it’s given a more generic name, however in a client-server environment it simply means to force jobs to render on the workstation rather than optionally on the server. This change improves server stability as if the crash exists in the driver’s rendering code, the issue would be limited to the workstation and one user only. To turn off Advanced printing features, follow the directions outlined here: Disabling Advanced Printing Features

Disable Bidirectional Support

If you identify a particular queue as problematic - e.g. Jobs always seem to jam in queue X - consider turning off the port’s bidirectional support as follows:

  1. On the print server, Start->Settings->Printers
  2. Right-click on the printer and select Properties...
  3. Select the Ports Tab
  4. Turn off Enable bidirectional support

Print vendors can implement a communication channel outside the supported operating system methods which can be enabled and disabled within the interface provided with the vendor specific code.

This option will turn off features in the driver related to tasks such as printer hardware status reporting. If issues/bugs existing in this area of the driver’s code, stability can improve.

Is there a way to disable Bidirectional Support automatically for all my printers?

Yes, but it should first come with a hefty dose of caution. Some print drivers rely on bidirectional support to detect whether a finishing unit is connect to the printer, or if the printer is in an error state. If you’ve tested this change on a few printers and decided you want to apply this to all of your printers now, then use the following PowerShell script to disable Bidirectional Support for all printers automatically. If running PowerShell commands on your production print server makes you a bit nervous, then follow our steps here to make a backup of your print server.

Open an elevated PowerShell window on your print server and run the following commands:

$printers = Get-Printer -Name *
foreach ($p in $printers) 
{
cscript c:\Windows\System32\Printing_Admin_Scripts\en-US\prncnfg.vbs -t -p $p.name -enablebidi
}

To do the opposite and enable Bidirectional support on all queues, you can run the script again but change the switch from minus -enablebidi to plus +enablebidi.

Quality Drivers

Try to stick to quality drivers from known vendors. It only takes one bad driver to take down the rest. If you suspect a particular driver is causing problems, consider hosting it on a separate print server so crashes do not affect all printers. Many of our larger Universities customers will run two print servers. One for the majority of printers and one for the misbehaving drivers!

Set Driver Isolation to ‘Shared’ or ‘Isolated’

If there is a corrupt driver or something else untoward going on with one of the print queues, you don’t want the entire print spooler to fall over. You can mitigate this by managing the Driver Isolation settings in Windows. These are the three options:

  • None - in this mode the Print Spooler and drivers share a process, called spoolsv.exe. One bad driver can crash everything.
  • Shared - which means ‘Run the driver in a process that is shared with other printer drivers but is separate from the spooler process’. In this mode, the all the drivers run in a single process, called printisolationhost.exe, which is separate from the Print Spooler. This is the most efficient option.
  • Isolated - which means ‘Run the driver in a process that is separate from the spooler process and is not shared with other printer drivers’. In this mode each individual driver will run in its’ own printisolationhost.exe process. It is best to enable this option when you believe you have encountered a buggy print driver.

Choosing one or the other should reduce the likelihood of a spooler crash happening on your server. None is the riskiest choice because it will crash your print spooler if you have a driver issue.

To change the driver isolation mode for an individual driver…

  1. Open Print Management by pressing Windows key + R, then type printmanagement.msc and hit the enter key.
  2. Navigate to the Drivers section, then right-click on the driver you want to manage.
  3. Hover over Set Driver Isolation… then choose one of the options.


To change this setting to Shared for an entire print server (recommended)…

  1. On the print server, open the Group Policy Editor, gpedit.msc.
  2. Navigate to Computer ConfigurationAdministrative TemplatesPrinters
  3. Right click on ‘ “Override print driver execution compatibility setting reported by print driver and set this to Enabled′ ’.
  4. Click OK and then exit. You may need to restart the print server for the changes to apply.

Monitoring

Computers are computers! Problems will occur. Put in place procedures to monitor your services and have a plan when problems occur. Make sure your Spooler Service is set to automatically restart on failure. PaperCut includes options to monitor print queues and can be configured to email administrators on problems.

Removing a single point of failure

Partitioning the problem print drivers on to another server as discussed above is one good strategy to isolate points of failure. Larger sites may consider more advanced methods such as server clustering and/or splitting load across multiple servers. These methods all engineer out single points of failure ensuring that a failure in one area may not affect all users and services. (e.g. a crash in the print server hosting the Engineering Department’s wide-format devices will not affect the servers hosting the standard laser printers for the other departments). PaperCut has full support for clustering and multi-server deployments.


Common Issues/Questions:

Q My spooler service has crashed and I think PaperCut was the cause?

PaperCut take a passive approach to print monitoring and it’s integration with the operating system is as follows:

  1. When a new job arrives it is Paused in the queue.
  2. PaperCut then reads the spool file to extract metadata (e.g. page counts, paper size, etc.)
  3. PaperCut then resumes the job.

No driver or spooler module level integration takes place.

We’ve seen issues (usually with lesser well known printers) where the pausing and resuming of jobs will sometimes cause driver bugs to surface more quickly. With Windows monolithic print spooler, all it takes is one bad driver! The following setting change usually address the issue: : Disabling Advanced Printing Features

Q My spooler service has crashed and I can’t restart it. It just re-crashes on startup. How do I fix it?

More likely this is caused by a corrupt spool file. Try the following procedure:

  1. Stop the Spooler Service under Control Panel -> Admin Tools -> Services
  2. Delete any files in C:\Windows\System32\Spool\PRINTERS
  3. Restart the spooler service stopped in 1.

Categories: How-to Articles, Print Queues


keywords: driver error, hung, lock, crashed, spooler, driver, stability, lockup

Comments