Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Y'know they way windows print queues will occasionally stop working with a print job at the head of the queue which just won't print and which you can't delete? Anyone know whats going on when this happens?

I've been seeing this since the NT4 days and it still happens on 2008. I'm talking about standard IP connected laser printers - nothing fancy. I support a lot of servers and loads of workstations and see this happen a few times a year.

The user will call saying they can't print. When you examine the print queue, which in my case will generally be a server based queue shared out to the workstations, you find a print job which you cannot cancel. You also can't pause it, reinitialize it, nothing.

Stopping the spooler is the usual trick and works sometimes. However I occasionally see cases which even this doesn't cure and which a reboot is the only solution. Pause the queue, reboot, when it comes back up the job can then be deleted. Once gone the printer happily goes back to its normal state. No action is ever necessary on the printer.

I regard having to reboot as last resort and don't like it. What on earth can be going on when stopping the process (spooler) and restarting it doesn't clear a problem?

Its not linked to any manufacturer either. I've seen this on HPs, lexmark, canon, ricoh, on lasers, on plotters.... can't say I ever saw this on dot matrix.

Anyone got any ideas as to what may be going on.

Ian

share|improve this question
1  
With my print server it seems to be jobs sticking at 64.0kb spooled for no apparent reason. Doesn't happen regularly enough for us to nail it down though - it's well known printers are evil. EEEEVIIIIIILLLLLL. –  tombull89 Oct 23 '12 at 9:59
2  
Million dollar question right here –  Dan Oct 23 '12 at 10:14
1  
@tombull89 LOL. Whenever I hear the words can't print its like another nightmare begins. I think we've all lost hours of our lives to these infernal machines. –  Ian Murphy Oct 25 '12 at 8:55
    
We used to schedule a bounce of the print daemon regularly but it didn't help. How many times can I +1 this question?! $1,000,000 question! –  Lizz Jan 5 '13 at 6:43
1  
In my experience, you can resolve this problem without rebooting by deleting the actual files from the spool directory while the spooler is stopped. I realize that doesn't answer your question, which is why I'm leaving it as a comment instead of an answer, but it seemed worth mentioning that you probably don't need to reboot. –  davidcl Mar 3 '13 at 18:56
show 3 more comments

1 Answer

My experience is usually a buggy print driver. I can't tell you how many times I've had to stop the print spooler service on Windows systems, navigate to the print spooler directory (usually C:\WINDOWS\System32\spool\PRINTERS), and delete the spool files there, then restart the print spooler service.

In my experience, it seems to mostly always be related to a font issue, which is a nightmare in the world of scanned PDFs.

Sorry I don't have a fix. Just wanted to let you know I feel your pain.

share|improve this answer
1  
Why are there any Adobe print products on a print server? –  MDMarra Mar 4 '13 at 21:04
    
I was behind you until you said the about about Adobe. Buggy print drivers are my stock answer. –  Evan Anderson Mar 4 '13 at 21:26
    
I meant the way adobe desktop products generate PDF's on client systems, which get sent to sprint servers. I agree it was poorly worded. –  churnd Mar 4 '13 at 23:21
1  
@churnd I can confirm that OCR done by various Adobe products is downright evil. Some of the glyphs are malformed which causes issues in the Windows font-engine which is called by the printer-driver to render the text. As the driver (and thus also the font-engine) is run in the context of the print-spooler process this can cause all sorts of havoc. –  Tonny Mar 5 '13 at 22:44
2  
There are a shitload of bad Tier-2 printer-drivers around that are based on the sample source-code once published in the MS SDK for Windows 2000. The SDK code had a bug: It didn't release a gdi-handle after rendering and printing a page. As a result the print-spooler process would loose a handle for each page printed. After 10.000 handles (hard limit set in the NT kernel, even in Win2012/Win8) the print-spooler crashes. You will only notice this if you print more than 10.000 pages between reboots. –  Tonny Mar 5 '13 at 22:54
show 8 more comments

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.