کد:
http://www.virtualizationadmin.com/articles-tutorials/terminal-services/printing/hunt-bad-printer-driver.html

When does the trouble start?

That is the weird thing with printer drivers. It’s extremely difficult to accept that drivers can be stable for months, and then all of a sudden cause major havoc on your server or farm. Once you have followed the basic advice within my surviving printing article, you will probably have the leasta mount of drivers on your server as possible, and those you have are thoroughly tested. (Yeah, right -> no time for that dude. The manager needs to print now, not tomorrow)
The list of trouble that a driver can cause is pretty large but to give you guys a starting point, here’s a summary of known printer driver related errors:
0xA - IRQL_NOT_LESS_OR_EQUAL
0x50 - PAGE_FAULT_IN_NONPAGED_AREA
0xBE - ATTEMPTED_WRITE_TO_READONLY_MEMORY
0xC1 - SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION
0xC4 - DRIVER_VERIFIER_DETECTED_VIOLATION
0xC6 - DRIVER_CAUGHT_MODIFYING_FREED_POOL
0xC7 - TIMER_OR_DPC_INVALID
0xC9 - DRIVER_VERIFIER_IOMANAGER_VIOLATION
If you hit one of the above errors start cleaning out the house. (Cleaning details coming up...)
And if you’re thinking that you can’t have that problem because you’re using the Citrix UPDIII, think again. Misbehaving drivers can even today disturb the new UPDIII CPSvc service and cause printing to halt. (This one usually manifests itself in you needing to restart the CPSvc service to get back up and running)
How to install and uninstall a driver

You’re probably thinking “what a stupid paragraph title that is.” As dumb as it may sound, even today people add drivers by installing the printer’s setup.exe routine, and removing the printer afterwards, leaving the driver on the server.
My personal preference is the .inf based driver, as it will save you that extra on software you probably don’t need on the server. (Assuming auto created printing, where the driver on the server is only used for ui options to prespool the job). For the fun of it, the way to go on the server is:
Start, Settings, Printers, File, Server properties, Drivers tab. Add/Remove.
From there you need to add and remove drivers. Does that mean that when using this method my system is always clean, mean and lean? No. Even when removing a driver via that location, the driver can still leave a fine mess behind.
Breaking down the driver

If you have a very basic driver then the driver installation is as follows:

  1. The INF file you’re installing from is copied to c:\windows\inf
  2. The DLLs that come with the driver end up in C:\WINXP\system32\spool\drivers\w32x86\3
  3. The driver’s information is written to:
    HKLM\SYSTEM\CCS\Control\Print\Environments\Windows NT x86\Drivers\Version-3\printername

As you see, nothing special mentioned above, and if you remove the driver via that same tab, all will be gone. In theory, that is.
Even when installing from a simple .inf file you will not be assured that it’s a “so called” clean driver.
Those INFs can also come with monitoring software for that printer. And monitoring software is NOT removed when using the above way of removing a driver. (Which is the official way of doing it, everybody will tell you)
Most printer drivers will add a “Print Monitor” as an entry in the registry:
HKLM\System\CurrentControlSet\Control\Print\Monito rs\printername
Now the entry is usually just referring to a DLL, but imagine when you are in the test phase of the server, and are trying out various drivers to see which one matches and behaves best with your end users’ printer. Then add those to the list of drivers that will be added and removed in a few months’ time.
You can add some serious garbage to your printing sub-system.
A clean system without any drivers installed will have the following keys which you should NOT remove:

  • BJ Language Monitor
  • Client Printer Port
  • Local Port
  • PJL Language Monitor
  • Standard TCP/IP Port
  • USB Monitor

Some other drivers may add an actual monitoring service to your system, even when installing via an .inf.
Lexmark and Dell (same stuff) are known for adding a service to monitor their driver. Make sure to check the services list before and after adding a printer driver to spot it.
Protecting your printing subsystem

So, how do you isolate that driver behavior, and keep things as clean as possible?
Basically just snapshot your printing subsystem before adding a new driver to it. This may sound as some work, and yes it is, but once you know the steps required it will add just 30 seconds to the job of adding a new printer driver to your server.

  1. First thing is stopping the spooler service. Then copy the actual driver files from the default location to your back up location. For example:
    copy C:\Windows\system32\spool\drivers\w32x86\3 c:\backup\prntdrv
  2. The second thing to do is to copy the registry keys that come with these drivers.
    In this case: HKLM\SYSTEM\CCS\Control\Print\Environments\Windows NT x86\Drivers\Version-3
    And key HKLM\System\CurrentControlSet\Control\Print\Monito rs
  3. Start the spooler service and add your new driver the regular way.

Once that’s done and users come back to you with complaints about printing stability, just stop the spooler service, clean out the \3 and the two registry keys and restore your backup. Fire up the spooler service, and all is honky dory. (Actually you got the users off your back, and it grants you the time needed to find out what’s going on with that new driver.)
The toolbox for fixing the existing environment

Some of you may be contractors or consultants being sent off to customers and often being asked to fix running issues. I am willing to bet that the number 1 thing you will be asked to fix is printing, and the second is probably profiles in combination with logon/logoff issues. In this article I will stick to printing.
The customer will probably have a huge list of errors they have encountered in the past. On that list you will find errors regarding printer or spooler service issues with just a reference to a DLL file. Well, good luck with just that small piece of information. You need a tool that will help you connect the installed driver on that server to the DLL causing the issues. If you’re running Windows 2000 server you need this tool:
http://www.printingsupport.com/tools/pdmanager.exe
If you’re on Windows 2003 server you need this one:
http://www.printingsupport.com/tools/iPrintSearch.exe
Both tools will give you the file details of the printer driver, making it very easy to find the match between the bad DLL and the driver it belongs to.
Once you have found your culprit driver and need to remove it from the server, do not use the official way via the drivers tab of the print server settings. That will leave too much garbage behind.
Kyocera has created a tool for a clean removal of their printer drivers, but the tool is go generic it works on all types of printer driver. Get your copy of the deleter here.
General cleanup

Once you have cleaned up that customer’s environment, make sure to leave it as lean and mean as possible. Consolidate drivers on the server using family drivers and mapping technology to minimize the number of drivers needed on the server. You will be surprised with the small number of drivers you can get by with. Explain to the customer the result of slacking in driver management. Where possible test drivers before deploying them to production. A simple vmware machine to stress test those new drivers a bit, will do just fine.
Conclusion

All the above advice will give you some extra work in the beginning, trying to get the hang of it. But if your farm is haunted by strange printing issues, it could be well worth the time spent. The basic protection in combination with the fast printing subsystem recovery will buy you that time to find out what’s going on, and it will not be after hours looking at it, but during regular working hours enjoying the daily routine with a hot cup of java



موضوعات مشابه: