Printer Driver Isolation in Windows 7 and Server 2008 R2

If you are not tired of print spooler crashes then this article is not for you. If you are, you may find a new feature of the upcoming next version of Windows interesting: printer driver isolation.

Some Background

In the dark ages of NT4 printer drivers were kernel drivers. From a reliability standpoint, that was a nightmare. Since printer drivers are not, have never been and probably will never be famous for stability, errors in printer driver code caused the computer to bug check (i.e. present the frustrated admin with a blue screen of death, BSOD).

Windows 2000 brought the major improvement of so-called version 3 drivers which are executed in user mode (although, for compatibility reasons, version 2 kernel mode printer drivers can still be used even today). Version 3 drivers are implemented as DLLs which are loaded by the print spooler (spoolsv.exe) whenever a specific driver is required in order to process a print job.

So far so good. Beginning with Windows 2000, buggy printer drivers do not bring down the entire machine, they "only" crash the spooler process. That may not be a big deal on single user systems, since the spooler is restarted automatically, but is a source for trouble on multi-user systems like terminal servers and on print servers. What often happens is this: a faulty printer driver crashes the spooler while processing a print job. The spooler is restarted and starts to pick up where it left off. The faulty driver gets a second go at the print job and crashes again.

Seen from a user's perspective, the printing subsystem is unreliable. The only remedy is to pick printer drivers very, very carefully, ideally using only inbox drivers, i.e. drivers that ship with the operating system. But that is not always practical.

Improvements to the Spooler in Windows 7

The logical consequence is to isolate printer drivers from each other and/or the spooler. Windows 7 and Server 2008 R2 achieve that by executing printer driver code not from within spoolsv.exe, but from a dedicated process, PrintIsolationHost.exe. In case of a driver causing a crash, only one instance of PrintIsolationHost.exe goes away, but the spooler service itself is left unperturbed.

Printer driver isolation is enabled by default and can be disabled via the following group policy setting:

Computer Configuration / Administrative Templates / Printers / Execute print drivers in isolated processes

This policy setting determines whether the print spooler will execute print drivers in an isolated or separate process. When print drivers are loaded in an isolated process (or isolated processes), a print driver failure will not cause the print spooler service to fail.

If you enable or do not configure this policy setting, the print spooler will execute print drivers in an isolated process by default.

If you disable this policy setting, the print spooler will execute print drivers in the print spooler process.

Notes:
- Other system or driver policy settings may alter the process in which a print driver is executed.
- This policy setting applies only to print drivers loaded by the print spooler. Print drivers loaded by applications are not affected.
- This policy setting takes effect without restarting the print spooler service.

Related Group Policy Settings

There is a second configuration option related to printer driver isolation: Computer Configuration / Administrative Templates / Printers / Override print driver execution compatibility setting reported by print driver.

Here is the explanation from the group policy editor:

This policy setting determines whether the print spooler will override the Driver Isolation compatibility reported by the print driver. This enables executing print drivers in an isolated process, even if the driver does not report compatibility.

If you enable this policy setting, the print spooler will ignore the Driver Isolation compatibility flag value reported by the print driver.

If you disable or do not configure this policy setting, the print spooler will use the Driver Isolation compatibility flag value reported by the print driver.

Notes:
- Other system or driver policy settings may alter the process in which a print driver is executed.
- This policy setting applies only to print drivers loaded by the print spooler. Print drivers loaded by applications are not affected.
- This policy setting takes effect without restarting the print spooler service.

When and How is Isolation Enabled?

How a driver is isolated depends on a number of factors. Firstly, the driver manufacturer must have marked it as compatible with isolation in the INF file. Either that, or the group policy setting "Override print driver execution compatibility setting reported by print driver" is enabled by the administrator. If neither is true, a driver is loaded into the spooler process as with previous Windows versions.

Note: all inbox drivers shipped with Windows 7 and Server 2008 R2 must support isolation.

All drivers to be isolated are, by default, loaded in one single process. They run in "shared mode". Using the print management console (PMC), this can be changed by right-clicking a driver and choosing either:

  • None: The driver is not isolated
  • Shared: The default. Load the driver into one process together will all other drivers in "shared" isolation mode.
  • Isolated: Load the driver into its own process. Recommended for troublemakers.

Analysis

Printer driver isolation is a very interesting new feature that promises to increase the stability of the printing subsystem, and with it the overall and perceived stability not only of print servers, but also of terminal servers and maybe even single user machines. The price to pay is reasonably low: slightly more overhead because the number of processes needed for printing is higher than with isolation turned off. All in all, it is a good thing that isolation is available and turned on by default, alas for inbox and new drivers marked as compatible only.

References

Miscellaneous

  • Microsoft filed a patent on printer driver isolation in 2003 which was published only a few weeks ago.
  • Many sources, including the explanation texts from the group policy settings cited above, use the term "print driver", which I feel is wrong. A driver does not "drive print" but "drive a printer". So it should be "printer driver" in my opinion.
  • If you want to check whether a specific printer driver supports isolation, look for the line "DriverIsolation=2" in the INF file.

++++ Wir suchen Verstärkung ++++ Arbeitskultur, IT Kompetenz und Innovation werden bei sepago zum Wohle unserer Mitarbeiter und Kunden maximal gefördert. Das ist der Sinn der sepago. Wenn Dich das anspricht, dann schau doch mal im Karrierebereich.

3 responses for "Printer Driver Isolation in Windows 7 and Server 2008 R2"

Very interesting feature.

Very interesting feature. Looking forward to RTM of Server 2008 R2. Thanks for the post!

The Official MSDN

The Official MSDN documentation says that by default Isolation is off. But you say it is on by default. Can you clarify?

Now coming to the Isolation per se, all XPS drivers/filters under Vista and even XP SP2 onwards run under the printfilterpipeline.exe, which is'nt the spooler process. It is only the v3 drivers(GDI based) that still run under the spooler process. And this new process (printfilterpipeline.exe) shuts down based on a timeout when there are no pending jobs to process. So another issue of a long executing process with memory leaks is longer valid.

Based on all this, should'nt we say that there was some sort of isolation for XPS filter right from Vista?

Let me have your comments on this?

great information - thanks

great information - thanks much. I was just researching because I have a new Win7 system in a network environment, but with a local printer, and the computer is getting an error whenever she tries to print that says "printisolation host has stopped working". She has rebooted, but still the same error and can't print from any application. What do you do in this case? Can you advise?

Microsoft Competence Blog

Application Infrastructure mit Microsoft Technologien ist ein wichtiges Fokusthema der sepago. Wir haben langjährige Projekterfahrung, sind neugierig auf neue Technologien und möchten diese bis in letzte Detail verstehen. Die Competence Blogs berichten davon.

RSS-Feed Alle Artikel des Competence Blogs abonnieren.

 

About the author

Bild von Helge Klein
Helge Klein
Consultant
Blogs about Windows, Terminal Services and other things

All articles

PM_Werbung_Free_Trial