Posted by: Jerry Lees
Development, Error control, Networking, Printer Administration, Printers, VBScript, Windows Management Interface
Recently, at my work we had a situation where users were reporting the printer was not printing their documents and/or it was printing very slowly. After digging into the problem, I found:
1. the documents were spooling just fine to the printer
2. the documents were not hanging in the printer
3. Sometimes there were documents printing correctly when the user printed
4. on occasion the documents “didn’t print”
Of course, the nearest printer doing it was on the floor below me… I hate stairs. After digging into it, wasting a ton of paper– and burning untold amounts of Mountain Dew and Dorito calories; I found that the print jobs were always producing printouts! Sometimes it was the document I printed and sometimes it was a single page with the following message in the documents place:
Subsystem: KERNELError: IllegalStreamHeaderOperator: 0×0
The operator and position line held various values, but was always the same first 3 lines. What I found after extensive digging was that this issue was a PCL6 error message. Some people were saying it was a network error and others were saying it was a server print driver error– Don’t they always say it’s one of these, regardless of the problem?
Those who were saying it was a network error were advising that I pulled out a sniffer, like wireshark because packets were being corrupted. I didn’t think this was good advice. First, pulling a sniffer out to troubleshoot printing was like pulling a blowtorch out to light a campfire… sure it will work, but it’s a lot of extra work! Also, I knew that Microsoft printing is done like most things Microsoft– over TCP ports 138,139, and 445 (I believe)– most importantly TCP, since TCP has error correction built in via a checksum.
The others who were saying it was a server issue were recommending that I upgrade ALL the printer drivers on the server. This was quite an undertaking since there were 40 or so printers on the server of various models– most of them made by HP. Knowing HP, the drivers were bundled together into one package and upgrading the drivers for one printer would likely change a bunch of printers. To much risk!
I did find a few needles in the google hay stack, that were saying the problem was typical for PCL6 and to simply switch the driver back to PCL5. Since both driver types were installed when I installed the printer drivers (always a good idea) I thought I’d give it a shot. Tah Dah! It worked like a charm, with no changes in the documents printer that I could see.
Now that I had one printer fixed, but had to point and clickety click to find the other’s using PCL6 drivers. To much work! So I wrote a quick script to get the bulk of the printer drivers that were being used by the print server so I could focus on the ones needing changing.
Here is the script source, copy it to a .vbs and either; run it from the print server as is or change the second line between the quotes from a period to the name of the print server: (Note: I recommend you run this from the command line with cscript scriptname so you don’t get bombarded by popups)
On Error Resume Next
strComputer = “.”
Set objWMIService = GetObject(“winmgmts:\\” & strComputer & “\root\cimv2″)
Set colItems = objWMIService.ExecQuery(“Select * from Win32_PrinterDriver”,,48)
For Each objItem in colItems
Wscript.Echo “ConfigFile: ” & objItem.ConfigFile
Wscript.Echo “DataFile: ” & objItem.DataFile
Wscript.Echo “DriverPath: ” & objItem.DriverPath
Wscript.Echo “Name: ” & objItem.Name
Wscript.Echo “OEMUrl: ” & objItem.OEMUrl
WScript.Echo “_________________” & vbcrlf
That’s the end of the script! You’ll want to look at the “Name:” lines for the string PCL6. Not all drivers have PCL6 in the name, but a good majority do so it should save you some time!
Take a bit of that time to leave me a comment letting me know if this was helpful!