Jobs stuck in Print Queue on print server

Question

I have a Server 2003 machine acting as a print server for about 20 printers. There is 1 printer which we are having issues with and it has 104 documents in its queue.

I have attempted the "Cancel All Documents" and tried to manually cancel individual documents without success.

The print jobs state "Deleting - Sent to printer" under their status. It has been in this state for about 2 hours.

I do not believe restarting the spool is an option without effecting the other printers and we have Hold printer for a specific non windows printing friendly application, in which I can not loose the jobs for.

Solution 1

Restarting the print spooler generally doesn't drop print jobs it just stops accepting new ones. End users will notice but it won't be as bad as silently dropping a print job. In general I would say it is safe to restart the service on the fly.

More importantly I wanted to share this with you:

Occasionaly I've had experience with a corrupt print job in a printer queue. In those cases I've noticed

a. The print spooler won't stay started as long as the corrupt print job is present and the target printer is on
b. the print spooler won't let you delete the corrupt job through the GUI if the spooler is stopped
c. the printer won't print any other job until the corrupt job is completed or deleted.

To fix this you have to

1. Physically turn off the printer
2. start/restart the print spooler
3. delete the corrupted print job
4. turn on the printer

If you don't do 1-4 in exactly that order you get stuck in an endless loop fighting with a-c.

I can't promise you that your situation matches this experience but I think its worth considering the behaviour observed and the implications to how the process of printing/print spooling hands things along.

edit: In the opposite take to Evan's manipulation of the spool files. You can use the print queue on Windows (start - settings - printers or start - printers) and delete the job from the print queue using the Document menu - Cancel option.

The key is in his way of dealing with it the spool service has to be stopped in dealing with it my way the spooler has to be started. If you have physical access to the printer and it is convenient to turn it off you can use my method. If you don't have access to the physical printer you can use his method.

Solution 2

Bouncing the spooler service is the only viable choice that I'm aware of. In my experience, some jobs get "jammed" in a queue so "severely" as to require stopping the spooler server, clearing the files that represent the jobs out of the %SystemRoot%\System32\Spool\Printers folder, and re-starting the spooler service.

You're not going to lose any jobs that are already queued for other printers by bouncing the spooler service (you can demonstrate this yourself on another server or a client-- pause a printer, put some jobs in queue, and stop / restart the spooler serivce), but if you find that you have to go the route of deleting job files from the spool directory you'll have a hard time locating them amid the other spooled files for jobs you intend to keep.

(As an aside: Microsoft could do a lot of enhancemnet of the print spooler service, IMO, to alleviate situations like you're seeing. The print spooler service has languished in a state of relatively little enhancement throughout the last few releases of Windows. Printing isn't sexy, but it's often business critical.)

Edit:

Each print job is represented in the spool directory by a ".SPL" file (containing the print job data in EMF or raw format) and a matching ".SHD" file, containing "header" information about the job. This header information file contains the details about which printer the job is being sent to.

Deleting the matching pair of the "SPL" and "SHD" files for a given print job effectively deletes that job.

Unfortunately, the format of the ".SHD" file is officially undocumented (see http://www.undocprint.org/formats/winspool/shd for some reverse engineered documentation), so figuring out "which file is which" in the spool directory and deleting only the "corrupt" print jobs is very difficult, at best. From what I can see, the destination print queue name is in that "SHD" file as a uncode string, so I suppose it would be possible to cobble together a script using command-line tools line "strings" and "findstr" to grovel thru all the ".SHD" files to find jobs destined for the "problem" printer and delete them while leaving jobs bound for other printers untouched.

Any manipulation of the spool files has to be done with the spooler service stopped because, while it's running, the files are locked.

Comments

[Deb]

+1. It's especially bad when a job gets in there that crashes the spooler service. No way to clear that out but to empty the spool directory itself. This is bad when the print-server in question services 150 printers.

[Spence]

@sysadmin1138: Absolutely! It seems like the spooler service is rife with bugs. Even if the problems stem from third-party drivers, unhandled exceptions shouldn't be able to take down the spooler service itself. Individual printers can fail, but when the whole spooler goes down it ends up being an emergency (the first time... then I wire the service up to restart itself... the next time I write a script to move the contents of the spool directory to a date-named folder and restart the service when it crashes... etc, etc)

[Spence]

That list number behavior is a pain, eh? (Caught you between edits and was going to comment... heh heh...)

[Erik Nijland]

indeed. I didn't want to do abc + 1234 but didn't want to leave my answer hanging out of continuity either.

[Carl]

Exactly what do you mean by "delete the corrupted print job"? Delete from Spool or delete some other way?

[Spence]

@Carl: I dropped an edit on explaining how the print jobs are stored.

[Carl]

I got it solved. I unplugged the printer, restarted the spooler, and plugged the printer back in and it worked. Thanks.