Windows Thread, Spooler consuming high CPU - multiple erroneous \PIPE\Spoolss in Technical; One of our servers (2003 Standard SP2, configured as DC + File/Print server for admin offices) has a print spooler ...
17th March 2008, 02:56 PM #1
Spooler consuming high CPU - multiple erroneous \\PIPE\Spoolss
One of our servers (2003 Standard SP2, configured as DC + File/Print server for admin offices) has a print spooler consuming excessive (60-80%) cpu. Users have multiple \\pipe\spoolss sessions open which immediately reopen if I force them closed, despite no print jobs being in the queue. Pipes remain open even if the user is no longer logged onto the machine. Shutting down the remote machine is the only thing that ends the session and reduces CPU use on the spooler.
Things I've tried so far:
Rebooted the server, deleted all printers, ripped out all printer drivers, checked for updates, and then replaced with new or known good versions (that work ok on a similarly patched server). Didn't reinstall the newest printer (HP3005dn) for good measure, just in case it was the culprit. For reference, the same model printer using the same drivers shared on another server works fine - no excessive spooler cpu consumption.
After the reboot, cpu use was normal until 10am this morning when it ramped up again and is currently sat at 93%. The event logs show a lot of print jobs where pages printed = 0.
I know that document is 2 pages long at least, and I'm getting a fair few of these, so I'm assuming that the spooler is dropping jobs because of the load.
Document 104, staff telephone list 0708.xls owned by USERNAME was printed on MO-BWLaser via port IP_$IP Size in bytes: 117151; pages printed: 0
Software-wise the only changes we've made recently is updating the clients to office 2003, but it's been 3 weeks since we did this and excessive cpu consumption by the print spooler started on Friday, flagged up by Nagios.
Google reveals similar problems occuring on earlier patch versions of 2003 Server, specifically with XP clients, but the fix was part of XP SP1 (we're on SP2 + security/critical). http://support.microsoft.com/kb/835318/en-us.
IDG Tech News
17th March 2008, 03:02 PM #2
Is there any chance that the workstations that are locking things up have one of the following:
- printer monitor software installed
- old versions of drivers (or the above)
- old "printers" pointing to the same printershare but with the wrong drivers set
Only other thing I can think of is a clash between a recent Winupdate and the printer drivers.
Wild assed guesses all I'm afraid but maybe they'll nudge something loose.. Best of luck.
17th March 2008, 03:30 PM #3
No print monitor software and it's actually the server that's getting the high cpu, but stripping the drivers and any local printers (there shouldn't be any) from clients couldn't hurt.
17th March 2008, 04:27 PM #4
You say you're using 2003 SP2, (which is fine), but by what method are you pushing out/distributing printers?
I personally use Print Management which comes part of 2003 R2. The advantage here is printers can be pushed out via GPOs and not scripts. Also, when you update the driver on the print server, the new driver is automatically pushed out to workstations on the network.
Is it possible you still have old drivers (as already mentioned) on workstations or the workstations have old printers pointing to the same TCP/IP port? This causes all kinds of problems.
17th March 2008, 04:54 PM #5
We're using GP deployment via pushprinters.exe. Workstations shouldn't have old drivers / printer mapping and most of the admin boxes were reimaged recently, I'm currently prowling around checking ones I'm not sure about.
Update: Ok, I'm satisfied it's not an old driver, all clients are using the current one - I think the culprit is HPBOID.dll and other assorted HP guff, so I'm investigating how to remove this and keep a working driver.
Last edited by pete; 17th March 2008 at 06:55 PM.
17th March 2008, 06:54 PM #6
Then you are using R2 Print Management. Within Administrative Tools on the Start Menu (on your print server), look for Print Management.
Seeing as you are using R2 Print Management, I would encourage you install the latest print driver on your print server, then check (after a workstation reboot) whether that driver is then being used on the workstation.
In my experience, when installing HP printers, they create a HP TCP/IP port. You need to create a standard TCP/IP port and delete the HP port. It's a load of rubbish and creates nothing but problems!
17th March 2008, 07:39 PM #7
Small addendum to that re: HP printer drivers.
Originally Posted by Michael
In some cases even installing the new printer driver to the machine doesn't clear the issue and requires any and all printers to be removed and then re-added from the workstation.
Had this happen with an HP L7680 with the 8.0.1 version driver installed but it was still using the older one for the printer in the printer list. Weird didn't cover it
17th March 2008, 07:40 PM #8
what event id are there errors you are getting on the server that are related to the printing ?
17th March 2008, 07:49 PM #9
With R2 Print Management you don't have to remove printers manually. Printers are added dynamically everytime a user logs on (in my case) as I deploy on a per user basis.
To prove my theory, if you take a look at a workstation printers from My Network Places, the printers are not listed.
I agree also, the next step is taking a look at the event logs. Both server and local machine. You can do this all from MMC.
18th March 2008, 11:57 AM #10
# Event logs
Other than 0-page print jobs, mentioned earlier, the event logs on client and print server show nothing out of the ordinary. As far as the client and server are concerned printing is happening ok. None of my users have complained that things aren't getting printed.
# Standard TCP Connections for printers
Yep, we do that anyway, excessive printer guff causes too much grief.
We're already using the latest versions of the drivers from HP - even the minimal drivers install unnecessary guff.
I did find this: http://forums11.itrc.hp.com/service/...hreadId=370850
the cause is different, but the symptoms are similar. We don't have HPBPRO.EXE running on the server, but one of my suspects is the BOID.dll, which was holding a lot of connections open (and is installed as part of the HP driver).
So I deleted the printers from the server, ripped off the HP drivers again and commented out the HPBOID.dll and HPPRO*.dll entries in the .inf. I then re-added the driver and printers.
My users have been in since about 7:30, cpu usage on the server has stayed below 25% and printing is going fine.
18th March 2008, 12:05 PM #11
This might be useful
I find that a lot of problems are solved by deleting and reconnecting printers on logon. This script does just that, also has the advantage that if done in the computer settings in AD, it gets rid of printers the profile might have picked up else where.
Its a VBS script.
'printer script for non ict suite computers.
On error resume next
Set wshNetwork = CreateObject("WScript.Network")
'remove old printers
'add ict suite printer but do not make it the default.
Set wshNetwork = CreateObject("WScript.Network")
'add the forum BW printerand make it the default.
'add the ICT BW printer
'add the PPA BW printer.
'add the PDF creator
18th March 2008, 12:18 PM #12
Impressive work Pete, I hope your changes work for you
18th March 2008, 01:37 PM #13
Grr, spoke too soon.
And yet again, nothing useful in the event logs. Back to the drawing board.
Service Warning[18-03-2008 11:57:02] SERVICE ALERT: SERVERNAME;CPU Load;WARNING;SOFT;1;CPU Load 83% (5 min average)
18th March 2008, 02:44 PM #14
Have you tried this:
Change to the System 32 folder by typing cd\winnt\system32
for Win2K or cd\windows\system32
Run the command "hpbpro.exe -RegServer".
Then run the command "hpbpro.exe -Service".
Then type "Exit" and then restart your PC.
19th March 2008, 02:50 PM #15
Yeah, that particular .exe wasn't present on the clients or the server. I remotely restarted all the client workstation print spoolers, which dropped cpu use down to normal levels on the server yesterday, but it's 13:49 and Nagios is about to notify me of unacceptable cpu load again.
It's report season here until Thursday, so I can't get at the workstations at the moment.
By Kyle in forum Hardware
Last Post: 20th September 2012, 03:42 PM
By burgemaster in forum Windows
Last Post: 22nd May 2008, 08:50 PM
Last Post: 11th November 2007, 06:24 PM
By BKGarry in forum Windows
Last Post: 7th September 2007, 08:20 AM
By Nij.UK in forum Windows
Last Post: 16th May 2006, 11:13 AM
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)