A few times a month Print Logger users email us with print queue/spooler stability issues. Although the issues in most cases do not related to Print Logger, 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 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. 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 Print Logger 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. We recommend considering the following steps to improve reliability:

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

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!

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. (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). Print Logger has full support for clustering and multi-server deployments.

Common Issues/Questions:

My spooler service has crashed and I think Print Logger was the cause?

Print Logger (Unlike similar software) 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. Print Logger then reads the spool file to extract metadata (e.g. page counts, paper size, etc.)
3. Print Logger 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

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.