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:
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.
New Rasterization Service for Print Drivers
CSS Global Technical Readiness (GTR) Team
The XPS print path,
introduced in Windows Vista and Windows Server 2008, did not provide any
rendering services and therefore placed a higher burden on vendors
developing drivers with support for the XPS print path. Rendering
services provide the ability within the printing subsystem to convert a
print job into a format that can be sent to the printer. In the GDI
print path, the operating system provides rendering services that
support conversion to raster, printer control language (PCL),
PostScript, and HP-GL for output.
A rasterization
service enables printer drivers to render a print job and send it to
the printer in PDL format. In Windows 7 and Windows Server 2008 R2, the
XPS Rasterization
service (XPSRas) provides print driver developers with the capability
to rasterize XPS content in the Windows print path. This service enables
printer driver developers to provide better support for printers and
other document peripherals on the Windows platform and provides an XPS
service that is better than the rasterization capability provided in
previous versions of Windows.
|
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.
Printer Driver Isolation
CSS Global Technical Readiness (GTR) Team
The Printer Driver
isolation feature of Windows 7 and Windows Server 2008 R2 allows some
print driver functionality to be executed in a process, or processes,
separate from the print spooler. By invoking print drivers in a separate
process, problems associated with faulty print drivers are isolated
from the Print Spooler service and will not cause it to fail. In
addition, the ability to isolate print drivers from each other further
increases the reliability of the printing system.
Prior to Windows 7 and
Windows Server 2008 R2, the failure of third-party drivers was a leading
print server support issue at Microsoft. The crash of a driver loaded
into the print spooler process would crash the process, leading to an
outage of the entire printing system. The impact of a spooler crash on a
print server is particularly significant because of the number of users
and printers that are typically affected.
In addition to the benefit of improving overall printing system stability, this new feature provides a means to:
The Printer Driver
isolation feature is not intended to isolate print driver functionality
from applications other than the print spooler. If an application loads a
print driver into its own process space and the driver crashes, then
the application might crash as well. For example, if an application
directly calls into a printer's configuration module to set or get print
capabilities, a failure in the configuration module will crash the
application itself. In this scenario, the application is directly
loading the printer driver into its process space. If the print driver's
rendering module is loaded in the process space of the application, a
failure in the driver will again cause a crash of the application
itself.
|