Managing Printing : How Printing Works in Windows 7

Understanding how printing works in Windows 7 is important for administrators who need to know how to configure, manage, and troubleshoot printers and printing on this platform. The key topics to understand are:

• XPS

• The Windows printing subsystem

1. Understanding XPS

XPS is a platform-independent, royalty-free, open-standard document format developed by Microsoft that uses XML, Open Packaging Conventions (OPC), and other industry standards to create cross-platform documents. XPS was designed to simplify the process for creating, sharing, viewing, printing, and archiving digital documents that are accurate representations of application output. Using APIs provided by the Windows SDK and the Microsoft .NET Framework 3.0, developers can create Windows Presentation Foundation (WPF) applications that take advantage of XPS technologies.

XPS support, which is native to Windows Vista and later versions, allows users to open XPS documents in Internet Explorer 7.0 or higher and to generate XPS documents from any Windows application using the Microsoft XPS Document Writer. When you install additional features, some earlier versions of Windows can also use some of the capabilities of XPS:

• By installing the .NET Framework 3.0 redistributable on Windows XP Service Pack 2 (SP2) or Windows Server 2003, users of these platforms can open XPS documents using Internet Explorer 6.0 or later versions.

• By installing Microsoft Core XML Services 6.0 on Windows XP SP2 or later versions, users can generate XPS documents from any Windows application using the Microsoft XPS Document Writer.

• By installing the Microsoft XPS Essentials Pack and Microsoft Core XML Services 6.0 on Microsoft Windows 2000, Windows XP, or Windows Server 2003, users can open XPS documents in a stand-alone XPS Viewer application.

Note:

You can download these additional features from the Microsoft Download Center at http://www.microsoft.com/downloads.

You can find detailed information on XPS in the version 1.0 document for this specification at http://www.microsoft.com/whdc/xps/downloads.mspx on Microsoft Windows Hardware Developer Central (WHDC). You can find additional news concerning this specification on the XPS Team Blog at http://blogs.msdn.com/xps/.

2. Understanding the Windows Printing Subsystem

The print subsystem on versions of Windows earlier than Windows Vista used the GDI print path. The GDI print path processes print jobs as follows:

• Client processes When a user on a client computer sends a print job from an application, the application calls the GDI, which then calls the printer driver for information about how to render the print job in a format that the printer can understand. The printer driver resides on the user's computer and is specific to the type of printer being used. After the GDI renders the print job, it sends the job to the spooler. By default on Windows 2000 and later versions, the GDI renders print jobs using the Enhanced Metafile (EMF) format, a standard print job format that is highly portable but needs to be further rendered by the spooler before being sent to the printer. When an EMF print job is sent to the spooler, control returns to the user and the spooler then completes rendering the job for printing. (Because the EMF job is quickly handed off to the spooler, the time during which the user's computer is busy is minimized.)

• Spooler processes The print spooler is a collection of features that resides on both the client computer that sends the print job and a network print server that receives the job for printing. The spooler takes the job as rendered by the GDI and, if necessary, renders it further to ensure that it prints correctly. The spooler then hands the job off to the printer.

• Printer processes The printer receives the print job from the spooler, translates it into a bitmap, and prints the document.

Beginning with Windows Vista, the printing subsystem still includes a GDI print path (for Type 3 – User Mode) to support printing to existing printers. Kernel-mode GDI (Type 2 – Kernel Mode) drivers, however, are no longer supported.

Note:

Type 3 (User Mode) means that the driver is compatible with Windows 2000, Windows XP, Windows Server 2003, Windows Server 2003 R2, Windows Vista, Windows Server 2008, Windows 7, and Windows Server 2008 R2.

Beginning with Windows Vista, the printing subsystem also includes a second print path that is based on XPS. This additional print path, called the XPS print path, is built on the XPS printer driver model (XPSDrv) and provides the following benefits over the GDI model:

• Maintains the XPS document format from the point when an application sends a print job to the final processing by the print driver or device. By comparison, the GDI print path first renders the job into EMF, and then the print driver or device renders the job a second time into the language the printer can understand.

• The XPS print path can be more efficient and can provide support for advanced color profiles, which include 32 bits per channel (bpc), CMYK, named colors, n-inks, and native support of transparency and gradients when XPS-capable printers are being used.

• Provides "what you see is what you get" (WYSIWYG) printing.

Applications can print documents in Windows Vista and later versions by using either the GDI or XPS print path. For example, if a Win32 application sends the print job to a print queue that uses a GDI-based print driver, the print job is processed using the same GDI print path used in previous versions of Windows. However, if a WPF application sends the job to a print queue that uses a new XPSDrv print driver, the job is spooled using the XPS Spool File format and is processed using the XPS print path. The print path taken by the print job is therefore determined by the type of printer driver (GDI-based or XPSDrv) installed on the target print queue.

Figure 1 illustrates the two print paths (GDI and XPS) available in Windows Vista and later versions. Although not shown in the diagram, both of these paths use the same Print Spooler service (%SystemRoot%\System32\spoolsv.exe).

Depending on the presentation system of the application from which the document is being printed, the print job might need to be converted before being spooled in the target print path. For example, when you print from a Win32 application to an XPS-capable printer, GDI spooling functions must perform GDI-to-XPS conversion, which simulates a WPF application and spools the job in XPS Spool File format. Similarly, when you print from a WPF application to a legacy GDI-based printer, the WPF Print Support functions must perform XPS-to-GDI conversion, which simulates GDI calls by a Win32 application and spools the job in EMF format. These two conversion technologies are built into Windows Vista and later versions for maximum application compatibility when printing from different kinds of applications to either legacy or XPS-capable printers.

For more information on the XPS print path and XPSDrv print drivers, see the white paper titled "The XPSDrv Filter Pipeline" on WHDC at http://www.microsoft.com/whdc/device/print/XPSDrv_FilterPipe.mspx.

3. Understanding Printer Driver Isolation

Printer driver isolation is a new feature of the printing subsystem in both Windows 7 and Windows Server 2008 R2 that can increase the stability of print servers by allowing administrators to isolate unstable printer drivers within a separate PrintIsolationHost.exe process instead of within the spooler process. The advantage of doing this is that when an unstable printer driver crashes, the crash doesn't halt the spooler, which would stop all other printers from functioning on the print server.

When the Print Server role service of the Print and Document Services server role is installed on Windows Server 2008 R2, each printer driver on the print server can run in one of three possible driver Isolation modes:

• None In this mode, the printer driver will run in the spooler process and not in a separate process. If a driver crashes, the spooler will crash, and administrators must restart the Print Spooler service. All print queues on the server will be offline while the spooler is offline. This mode is the only option on Windows 2000, Windows 2003, and Windows 2008 print servers.

• Shared The printer driver will run in a separate process with all of the other drivers that are also configured in Shared mode. If the driver crashes, the spooler will not crash, but all print queues with drivers in the shared process will be offline (print queues with drivers in isolated processes or within the spooler process will remain online). The shared process will be recycled, the drivers in it will be restarted, and the queues associated with these drivers will return to the online state.

• Isolated In this mode, the printer driver will run by itself in a separate process isolated from all other drivers. If the driver crashes, only the print queue associated with this driver will be offline. The isolated process will be recycled, the print queue will be restarted, and the queue associated with the driver will return to the online state. No other print queues or drivers on the server will be affected by this crash/restart.

Therefore, a Windows Server 2008 R2 print server can have the following:

• Legacy mode (always present)

• Shared process (always present)

• One or more isolated processes (optional)

Note:

The default driver Isolation mode for in-box printer drivers in Windows 7 and Windows Server 2008 R2 is Shared, whereas the default driver Isolation mode for virtual printer drivers (such as the Microsoft XPS Document Writer), fax, and print-to-file drivers (such as Print To OneNote) is None. Group Policy and .inf settings can override these System Default driver isolation settings.

Printer vendors can indicate whether a particular printer driver that they provide has been tested and verified to support running in a shared or isolated process. They can do this by adding a DriverIsolation entry in the Version section of the .inf file for the driver. For example, the following .inf file entry indicates that the driver does not support running in a separate (shared or isolated) process.

[Version]
...
DriverIsolation=0

The following .inf entry indicates that the driver can be run in a separate process.

[Version]
...
DriverIsolation=2

Note:

The values 1 and 3 for DriverIsolation are reserved for future use. Any value other than DriverIsolation=2 assumes DriverIsolation=0.

Regardless of whether this .inf file entry is present or what its value is, administrators can override this setting and configure driver Isolation mode for any print driver by using the Print Management console. Administrators can also configure global driver isolation settings by using Group Policy.

Note:

Print servers might experience a small degradation of performance when driver isolation is implemented due to the increased number of processes running on the system and the additional interprocess communication overhead incurred when the driver calls spooler functions, and vice versa. Additional temporary performance degradation might also be incurred when a new process is created or needs to be recycled. This performance degradation is much more evident when there are many drivers running in Isolated mode than when using Shared mode.