Fixing Print Spooler Crashes - improving print spooler stability

KB Home   |   Fixing Print Spooler Crashes - improving print spooler stability

Main.FixingPrintSpoolerCrashes History

Hide minor edits - Show changes to output

March 30, 2018, at 04:27 PM by Aaron Pouliot - Added Category Windows
Changed line 67 from:
''Categories:'' [[Category.Troubleshooting|+]]
to:
''Categories:'' [[Category.Troubleshooting|+]], [[Category.Windows|+]]
January 30, 2015, at 09:32 PM by Alan Morris - added comment on vendor provided software
Added lines 30-31:
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.
Added line 34:
Changed line 66 from:
[-keywords: driver error, hung, lock, crashed, spooler, driver, stability -]
to:
[-keywords: driver error, hung, lock, crashed, spooler, driver, stability, lockup -]
Changed line 22 from:
!! #Disable Bidirectional Support
to:
!! Disable Bidirectional Support
Changed lines 21-22 from:
!![[#Disable Bidirectional Support]]
to:
[[#disbidirect]]
!! #Disable Bidirectional Support
Changed line 21 from:
!!Disable Bidirectional Support
to:
!![[#Disable Bidirectional Support]]
Changed lines 62-64 from:
to:
----
''Categories:'' [[Category.Troubleshooting|+]]
----
Changed lines 38-39 from:
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  PaperCut has full support for clustering and multi-server deployments.
to:
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.
Changed line 63 from:
[-keywords: driver error, hung, lock, crashed, spooler-]
to:
[-keywords: driver error, hung, lock, crashed, spooler, driver, stability -]
Changed lines 27-28 from:
# Turn off [@Enable bidirectional support@]
to:
# Turn '''off''' [@Enable bidirectional support@]
Changed lines 41-42 from:
!Common Questions:
to:
!Common Issues/Questions:
Changed lines 16-17 from:
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 spoolers 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.  We recommend considering the following steps to improve reliability:
to:
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.  We recommend considering the following steps to improve reliability:
Changed lines 19-20 from:
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 crash would be limited to the workstation only and one user.  To turn off Advanced printing features, follow the directions outlined here: [[EnableAdvancedPrintingFeatures|+]]
to:
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: [[EnableAdvancedPrintingFeatures|+]]
Deleted line 30:
Changed lines 35-36 from:
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.
to:
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 [[https://www.papercut.com/products/ng/manual/ch-sys-mgmt-sys-nofications.html#ch-sys-mgmt-sys-notifications-error|email administrators on problems]].
Changed lines 38-39 from:
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  PaperCut has full support for clustering and multi-server deployments.
to:
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  PaperCut has full support for clustering and multi-server deployments. 
Changed line 63 from:
[-keywords: hung, lock, crashed, spooler-]
to:
[-keywords: driver error, hung, lock, crashed, spooler-]
Changed lines 3-4 from:
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 PaperCut users.  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 with sites with very high volume print environments.
to:
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.
Changed lines 7-12 from:
* The print queues randomly lock up from time to time.  And problem jobs can't be cleared!
* The print spooler service ([@spoolsv.exe@]) crashes.
* The print spooler service hands 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 related
to events such as printing a particular type of print job.
to:
* 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.
Changed lines 19-20 from:
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 crash would be limited to the workstation only and one user.  To turn off Advanced printing features, follow the directions outlined here: [[EnableAdvancedPrintingFeatures+]]
to:
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 crash would be limited to the workstation only and one user.  To turn off Advanced printing features, follow the directions outlined here: [[EnableAdvancedPrintingFeatures|+]]
Deleted line 34:
Changed lines 1-4 from:
(:title Fixing Print Spooler Crashes:)

A few times a month we have 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 PaperCut users.  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 from working with users in very high volume print environments.
to:
(:title 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 PaperCut users.  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 with sites with very high volume print environments.
Changed lines 13-14 from:
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! 
to:
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!)-] 
Changed lines 16-20 from:
Most print spooler crashes are caused by bad drivers (driver bugs).  Unlike other print queue architectures like CUPS on Linux, the print spooler system on Windows in monolithic -  It works as a single process and loads driver code into the spoolers process address space.  This means that any crash in a driver will not only bring down the current job, but also the queue as a whole affecting all printers.  We recommend considering the following steps to improve reliability on Windows:

!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!

to:
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 spoolers 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.  We recommend considering the following steps to improve reliability:
Changed lines 19-20 from:
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.  That way a driver crash will only occur on the workstation and not the server.  This is done by turning off ''Advanced Printing Features''.  Detailed discussion can be found here: [[EnableAdvancedPrintingFeatures|+]]
to:
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 crash would be limited to the workstation only and one user.  To turn off Advanced printing features, follow the directions outlined here: [[EnableAdvancedPrintingFeatures+]]

!!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:

# On the print server, [@Start->Settings->Printers@]
# Right-click on the printer and select [@Properties...@]
# Select the [@Ports@] Tab
# Turn off [@Enable bidirectional support@]

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.


!!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!


Changed lines 3-4 from:
This is a general article not specifically related to PaperCut, however is a collection of knowledge we have gather over the years from working with users in very high volume print environments.  This article applies to Microsoft Windows.
to:
A few times a month we have 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 PaperCut users.  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 from working with users in very high volume print environments.

Print queue stability issues usually manifest as follows:
* 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.  And problem jobs can't be cleared!
* The print spooler service ([@spoolsv.exe@]) crashes.
* The print spooler service hands 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 related 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 print spooler system on Windows in monolithic -  It works as a single process and loads driver code into the spoolers process address space.  This means that any crash in a driver will not only bring down the current job, but also the queue as a whole affecting all printers.  We recommend considering the following steps to improve reliability on Windows:

!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!

!!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.  That way a driver crash will only occur on the workstation and not the server.  This is done by turning off ''Advanced Printing Features''.  Detailed discussion can be found here: [[EnableAdvancedPrintingFeatures|+]]

!!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.

!!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  PaperCut has full support for clustering and multi-server deployments.

----
!Common Questions:

Deleted lines 52-66:
!General Discussion
Most print spooler crashes are caused by bad drivers (driver bugs).  Unlike other print queue architectures like CUPS on Linux, the print spooler system on Windows in monolithic -  It works as a single process and loads driver code into the spoolers process address space.  This means that any crash in a driver will not only bring down the current job, but also the queue as a whole affecting all printers.  We recommend considering the following steps to improve reliability on Windows:

!!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!

!!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.  That way a driver crash will only occur on the workstation and not the server.  This is done by turning off ''Advanced Printing Features''.  Detailed discussion can be found here: [[EnableAdvancedPrintingFeatures|+]]

!!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.

!!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  PaperCut has full support for clustering and multi-server deployments.

Changed line 9 from:
# PaperCut then reads the spool file to extra metadata (e.g. page counts, paper size, etc.)
to:
# PaperCut then reads the spool file to extract metadata (e.g. page counts, paper size, etc.)
Changed lines 26-27 from:
Most print spooler crashes are caused by bad drivers (drive bugs).  Unlike other print queue architectures like CUPS on Linux, the print spooler system on Windows in monolithic -  It works as a single process and loads driver code into the spoolers process address space.  This means that any crash in a driver will not only bring down the current job, but also the queue as a whole affecting all printers.  We recommend considering the following steps to improve reliability on Windows:
to:
Most print spooler crashes are caused by bad drivers (driver bugs).  Unlike other print queue architectures like CUPS on Linux, the print spooler system on Windows in monolithic -  It works as a single process and loads driver code into the spoolers process address space.  This means that any crash in a driver will not only bring down the current job, but also the queue as a whole affecting all printers.  We recommend considering the following steps to improve reliability on Windows:
Changed lines 26-27 from:
Most print spooler crashes are caused by bad drivers (drive bugs).  Unlike other print queue architectures like CUPS on Linux, the print spooler system on Windows in monolithic -  It works as a single process and loads driver code into the spoolers process address space.  This means that any crash in a driver will not only print down the current job, but also the queue as a whole affecting all printers.  We recommend considering the following steps to improve driver reliability:
to:
Most print spooler crashes are caused by bad drivers (drive bugs).  Unlike other print queue architectures like CUPS on Linux, the print spooler system on Windows in monolithic -  It works as a single process and loads driver code into the spoolers process address space.  This means that any crash in a driver will not only bring down the current job, but also the queue as a whole affecting all printers.  We recommend considering the following steps to improve reliability on Windows:
Changed lines 29-30 from:
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 seperate 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.
to:
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!
Changed lines 38-39 from:
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  PaperCut has full support for clustering.
to:
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  PaperCut has full support for clustering and multi-server deployments.
Added lines 5-14:
Q: My spooler service has crashed and I think PaperCut was the cause?

A: PaperCut take a passive approach to print monitoring and it's integration with the operating system is as follows:
# When a new job arrives it is Paused in the queue.
# PaperCut then reads the spool file to extra metadata (e.g. page counts, paper size, etc.)
# 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: : [[EnableAdvancedPrintingFeatures|+]]

Changed line 30 from:
[-keywords: hung, crashed, spooler-]
to:
[-keywords: hung, lock, crashed, spooler-]
Changed lines 28-30 from:
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  PaperCut has full support for clustering.
to:
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  PaperCut has full support for clustering.

[-keywords: hung, crashed, spooler-]
Changed lines 3-4 from:
This is a general article not specifically related to PaperCut, however is a collection of knowledge we have gather over the years from working with users in very high volume print environments.  This article applies to Windows.
to:
This is a general article not specifically related to PaperCut, however is a collection of knowledge we have gather over the years from working with users in very high volume print environments.  This article applies to Microsoft Windows.
Changed lines 19-20 from:
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 seperate print server so crashes do not affect all printers.  Many of our larger Unviersities customers will run two print servers.  One for the majority of printers and one for the misbehaving drivers.
to:
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 seperate 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.
Changed lines 6-8 from:
More likely this is caused by a corrupt spool file.  Try the following procedure:
to:

A:
More likely this is caused by a corrupt spool file.  Try the following procedure:
Changed line 16 from:
Quality Drivers
to:
!!Quality Drivers
Changed lines 19-24 from:
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.  That way a driver crash will only occur on the workstation and not the server.  This is done by turning off ''Advaned Printing Features''.  Detailed discussion can be found here: [[EnableAdvancedPrintingFeatures|+]]

Monitoring

Removing a single point of failure
to:
!!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.  That way a driver crash will only occur on the workstation and not the server.  This is done by turning off ''Advanced Printing Features''.  Detailed discussion can be found here: [[EnableAdvancedPrintingFeatures|+]]

!!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.

!!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  PaperCut has full support for clustering.
Added lines 1-24:
(:title Fixing Print Spooler Crashes:)

This is a general article not specifically related to PaperCut, however is a collection of knowledge we have gather over the years from working with users in very high volume print environments.  This article applies to Windows.

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:
# Stop the Spooler Service under [@Control Panel -> Admin Tools -> Services@]
# Delete any files in [@C:\Windows\System32\Spool\PRINTERS@]
# Restart the spooler service stopped in 1.



!General Discussion
Most print spooler crashes are caused by bad drivers (drive bugs).  Unlike other print queue architectures like CUPS on Linux, the print spooler system on Windows in monolithic -  It works as a single process and loads driver code into the spoolers process address space.  This means that any crash in a driver will not only print down the current job, but also the queue as a whole affecting all printers.  We recommend considering the following steps to improve driver reliability:

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 seperate print server so crashes do not affect all printers.  Many of our larger Unviersities customers will run two print servers.  One for the majority of printers and one for the misbehaving drivers.

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.  That way a driver crash will only occur on the workstation and not the server.  This is done by turning off ''Advaned Printing Features''.  Detailed discussion can be found here: [[EnableAdvancedPrintingFeatures|+]]

Monitoring

Removing a single point of failure

Comments

Share your findings and experience with other PaperCut users. Feel free to add comments and suggestions about this Knowledge Base article. Please don't use this for support requests.

Article last modified on March 30, 2018, at 04:27 PM
Printable View   |   Article History   |   Edit Article