Take the 2-minute tour ×

I have noticed that when a printer or driver screws up on a Windows server it usually locks up or kills the print spooler and everyone can't print until it is fixed. Usually we have to put the troublesome printer on another server so when it fails, it doesn't take the whole group with it. That is assuming we ever figure out which printer is the problem.

Is there a way to have it so that one bad apple doesn't ruin the bunch? Even if it is another form of printer serving, that would work as long as it's not hard for the user to find a printer and install drivers.

share|improve this question
add comment

6 Answers

up vote 8 down vote accepted

I know this doesn't help your current server situation, but something of note: Windows Server 2008 R2 and Windows 7 will allow you to setup Printer Driver Isolation. It allows you to run troublesome printers as a separate process, so they won't kill the spooler.

share|improve this answer
add comment

When we ran into problems like this, we found it was more related to mixed HP model print drivers on the print server than a bad driver. Once we moved all the HP printers to use the Universal print driver, our problems went away.

share|improve this answer
That still sounds like a bad driver to me. You just moved everything to using one non-bad driver. –  Evan Anderson Jun 24 '09 at 13:40
I guess technically, yes, it was a driver problem, but I don't think individually any of the drivers caused issues, it was only when mixing different models on the same print server we had trouble. –  Kevin Kuphal Jun 24 '09 at 14:25
Keep in mind... the universal drivers have been known to be very unreliable, despite the fact they seemed to work for you –  Brett G Oct 15 '09 at 23:46
add comment

We have just gone through similar issues. Certain documents printed by certain users to certain printers will completely screw the spool service on a win 2k3 server and because of that, knocks all of the other printers out.

We didn't really find a suitable way around avoiding taking out the whole spooler other than have many print servers which is obviously not very friendly. However, what we have done is created additional queues for problem printers which use either PCL or PS drivers (basically whichever one is not currently being used). Call it the same thing with -ps / -pcl after it and advise users who are having problems to print to that.

It is also worth checking in services.msc on the print server that the spooler service is set to auto-restart itself. That way you may get away with just a few moments of downtime.

I guess you could also advise that people who need to print to the dodgy printer, do so via direct IP printing thus eliminating the print server from the equation all together.

share|improve this answer
add comment

As a work around until you get a more functional driver for the faulting printer, is to have a script run when the spooler crashes (recovery properties on the service). Have the script clear all documents out of the spool directory and then restart spooler. There is a slight possibility of losing print jobs, but usually when I see this the only job in the queue is the offending job.

Other things to check are making sure you are at the latest driver versions, or going back one version. Make sure your printer and IO (Jetdirect?) firmware are up to date. Finally, I have found that the Standard TCP/IP Port is much more reliable that using the HP or vendor-provided port type. We have print servers doing more than 600,000 pages/month and the port type seems to have the most affect on whether the print server remains stable or not.


For the script (batch file), it would be something as simple as this:

del /q c:\windows\system32\spool\PRINTERS\*.*
net start spooler

Then run the batch file as part of the service recover on first failure. You may want to have notifications go out on subsequent failures.

print spooler

share|improve this answer
add comment

One way to do it would be to create several VMs, each with their own printer(or no more than a few printers per VM).

share|improve this answer
The problem with this is that every VM appears as a different server. –  Joseph Oct 22 '09 at 2:57
I'm going to nitpick for a second - they don't "appear" as different servers, they are different servers. Helpful advice - Now if you name your printers following a standard, publish them to AD directly, and train your users how to search for them, then you don't need them to know the server names (unless they get moved to new servers.) You can even put in location info, like "6th floor copy room, Des Moines" –  mfinni May 27 '10 at 19:33
add comment

What server OS? Is the print spooler service just stopping? If so, why not set the service to automatically restart if stopped?

share|improve this answer
Because when it fails like that, it won't start until the offending file is removed from the spool directory. And there is no easy way to figure out what that file is. The only way to recover is to remove ALL queued jobs from the spool directory and restart. This is too complex for the Windows service-manager. –  sysadmin1138 Oct 21 '09 at 17:05
Doug, below you, shows that this is not too complex for the Windows service manager. –  mfinni May 27 '10 at 19:34
/Meta - Hm - weird. I thought this was a new question, but after I commented, I see it hit the front page because Doug had edited his reply from last year to include further instructions and a screenshot. Never mind. –  mfinni May 27 '10 at 19:38
add comment

Your Answer


