Crashing Spoolers ? Printer Driver Isolation is coming!

Another nice 2008 R2 feature, I hadn’t paid attention to yet, is Printer Driver Isolation.

If, like me, you have (non pleasant) experiences with crashing Spoolers,
especially notorious on Terminal/Citrix Servers or high volume Print Servers with loads of diffent (3rd party) printer drivers,

you will probably be delighted by this new feature!

 

I haven’t seen it used in a production environment yet, but from what it looks like, it’s very promising.

 

Here’s some history of using Printer Drivers in the Real World:

In the Old Days (Pre W2K), Printer Drivers (called version-2) used to run in Kernel mode and could easily BSOD a printserver.

Beginning with W2K, Version-3 Printer Drivers were introduced, which run in User-Mode and can not BSOD a server,

“only” the Printing Subsystem (=Spooler Service=spoolsv.exe) in which the drivers were loaded.

 

As you probably know this is still a major concern for Print Servers, on which a spooler crash can have large impact,

if it hosts hundreds or even thousands of Print Queues, or if it happens regularly in Citrix farms where dozens of

users can be working on a server at the same time.

In Windows Server 2008 R2 (and Windows 7), Printer Driver Isolation (PDI) is introduced,

which means a bad behaving Printer Driver can only affect itself!

The isolation can be configure on a Per Driver basis, in three modes:

"None – in this mode, print driver components are loaded into the spooler process.  This is essentially the model found in previous versions of Windows

Shared – multiple drivers that are set for isolation are loaded into a single shared process space that is separate from the spooler process (PrintIsolationHost.exe) .  Although this protects the spooler process, the drivers that are in shared mode can affect one another

Isolated – each driver is loaded into its own process space.  This protects the spooler from individual driver failures, and also protects drivers from each other "

 

Basically the idea is this, at least this is probably how I would set it up:

-Run all well behaving drivers as ‘Shared’ (default)
-Run bad drivers as ‘Isolated’ if no suitable replacement is available
-Don’t run drivers in ‘None’, if necessary move those to separate server if you want a stable solution !

 

One approach for new drivers would be to start them off as ‘Isolated’,

and when proven innocent, ‘upgrade’ them to shared.

(The shared mode saves system resources as fewer isolation processes are needed).

On systems that don’t host a lot of print queues you could consider running them all isolated,

if resources are a non-issue.

 

Not all drivers will support isolation, I hope all companies that create Windows printer drivers will make them

compatible asap, so we can use it for all printers, to prevent problems, and have more control over our Print Servers.

 

The global settings can be managed using GPO, where you can disable or enable PDI,

and configure compatibility settings (override behaviour of compatible and incompatible drivers).

 

The PrintIsolationHost processes are only started when needed.

And there are registry settings that you can use to configure timeouts for the processes,

especially an option for restarting the Isolated processes after a certain amount of time,

so you can even handle drivers that are known to leak memory!

 

Of course, you shouldn’t use these, that’s why I said in the ‘Real World’ above 😉

There are often political, financial, historical or other non-technical reasons,

that some printers and especially their drivers have to be used, most of you probably know this.

 

At least know you have a way to handle these!

 

O yeah, the isolation settings are set per driver, and you can do so using the update PMC (Printer Management Console):

 

 

Have fun!