Improving Windows Print Spooler stability

“Help, users can’t print because the Print Spooler service on our Windows print server keeps stopping. Why does this happen and how can we get it working?”

Over the years we’ve worked with a number of PaperCut NG/MF customers who have encountered issues with the Windows Print Spooler service. In some cases we’ve even tracked the problem down to a specific print driver. This article describes some of the issues we’ve seen with the Windows Print Spooler, and shares the most effective fixes that we’ve been able to find.

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

• The print queue randomly hangs, and manually deleting the problematic job might resolve the issue.
• The print spooler service (spoolsv.exe) hangs or live-locks taking down all queues until manually restarted.
• The print spooler service crashes and errors will be logged in the Windows Event Monitor.
• Windows users may report that all their printers are “offline”, which happens if the Print Spooler service is not running (although there are other possible causes for that message).

The behavior might be random or could be correlated with high load on the print server. In some cases it may happen when users try to print from a certain application or print to a specific printer. Many times the behavior is completely unrelated to PaperCut, and happens regardless of whether the PaperCut NG/MF services are running.

By the way, if those bullet points above don’t quite line up with your symptom then check out one of these articles instead:

• Troubleshooting Missing or Disappearing Print Jobs
• Troubleshooting Disappearing jobs with Find-Me Printing
• Print Jobs stuck with the status of “Printing”
• Print Jobs stuck with the status of “Sent to printer”

Try stopping and starting the Print Spooler service

The first thing to try will be to restart the Windows Print Spooler for a quick fix. If you’re in the midst of an issue, here’s what we recommend:

1. On your Windows Print Server open services.msc.
2. Right click on the Print Spooler service and choose Restart. (For PaperCut customers you should see a prompt stating the PaperCut Print Provider will also be restarted, this is normal.)
3. Verify the print jobs have resumed.

What if that didn’t work? In an emergency, try this procedure to remove all spool files from the system. Just be warned that users will lose any queued print jobs.

1. On the Print Server, open services.msc.
2. Right click on the Print Spooler service and choose Stop.
3. Delete any files in the directory C:\Windows\System32\Spool\PRINTERS.
4. Back in services.msc right click on the Print Spooler service and choose Start.
5. If you are a PaperCut customer you will need to manually start the PaperCut Print Provider service as well.

If you’re lucky, the problem will go away at this point never to be seen again, but if you find that this needs to be done over and over again, then you’ll have to do something about the underlying cause. Below are some specific things you can try to prevent or mitigate the issue .

Look at the logs to track down the cause

How can you tell which print driver is causing the trouble? In a separate article we 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. This is also a great article to follow anytime you are seeing an application crash when trying to print.

Shift the rendering task to client workstations

A large chunk of the code of a print driver is responsible for rendering print jobs, so this is an area where many bugs exist. The task of rendering can be moved from the server to the workstations by turning off an option called Advanced Printing Features and by forcing Client Side Rendering. These changes improve server stability as any crash is now more likely to occur on the workstation and affect just one user. Note that a buggy driver will still cause a crash, but now it’s more likely for that crash to occur on the user’s workstation and affect just one user, as opposed to occurring on a print server and potentially affecting many more users.

Sandbox bad drivers with the Driver Isolation Mode

There’s one underused setting on Windows Print servers that can radically help improve system stability called the “Driver Isolation Mode”. Configuring this allows you to force print drivers to run in a separate process than the print spooler, which can prevent a buggy driver from crashing the Print Spooler service. Check out our article on managing the Driver Isolation Mode in Windows.

Try disabling Bidirectional Support

Many print drivers allow for an optional feature called Bidirectional Support which allows the print queue to communicate with the printer hardware to determine the printer’s status and other details. When troubleshooting consider disabling this feature to see if it resolves the issue. See our article on Bidirectional Support for instructions on how to manage this setting for a specific printer for an entire print server.

Still have questions?

Let us know! We love chatting about what’s going on under the hood. Feel free to leave a comment below or visit our Support Portal for further assistance.