Windows Printing Architecture

History

Microsoft describes Windows printing as an operating-system subsystem consisting of two cooperating parts: a print spooler and a set of printer drivers. Applications call device-independent functions, and the subsystem creates print jobs and routes them to many device classes, including laser printers, vector plotters, raster printers, and fax machines. Two ideas define the design. First, device independence: an application draws using a graphics API and does not need to know the target device's command language. Second, replaceable, layered components: the spooler and driver components are modular, so hardware vendors can add support for new devices, and in many cases supporting a new printer requires only new data files for a Microsoft-supplied driver.

The subsystem evolved in identifiable layers, each still partly present in modern Windows:

• GDI print path (the classic Win32 path). Applications call Graphics Device Interface (GDI) functions; the graphics engine either spools drawing instructions as an Enhanced Metafile (EMF) for later playback, or renders a printable image with the driver. Microsoft characterizes this path as similar to the Windows Server 2003 print path.
• XPS print path. Introduced with Windows Vista and built on the XML Paper Specification (XPS). Windows Presentation Foundation (WPF) applications and the XPS Print API spool jobs as XPS spool files, and XPSDrv drivers consume XPS directly. XPS-based technologies were also back-ported to Windows XP and Windows Server 2003 through the Microsoft WinFX Runtime Component 3.0.
• v4 driver model. A refinement of the v3 model, optimized for Windows 8 scenarios, simplified printer sharing (no per-architecture drivers), and easier development.
• Modern print platform / IPP. Windows 10, version 21H2, added inbox support for Mopria-compliant printers over network and USB via the Microsoft IPP Class Driver. Windows protected print mode shipped in Windows 11, version 24H2.

Architecture

The subsystem is a pipeline of replaceable components. All spooler components execute in user mode; the GDI graphics engine additionally has a kernel-mode part. Microsoft documents the following components and roles.

Client / graphics layer

• Application — creates a print job by calling GDI (Win32), the XPS Print API, or WPF print functions.
• GDI — has a user-mode part (Win32 GDI) and a kernel-mode part, the graphics engine, which exports services that graphics device drivers use.
• Winspool.drv — the client-side interface into the spooler; it exports the spooler's Win32 API and provides RPC stubs to reach the server. GDI is its primary client, but applications also call some functions.

Spooler service layer

• Spoolsv.exe — the spooler's API server, implemented as a service started at OS boot; it exposes the RPC interface to the server side of the spooler API.
• Router (Spoolss.dll) — decides which print provider to call based on the printer name or handle and forwards the call.
• Print providers — modules that support the specified print device (local versus remote); Win32spl.dll is the client module used for the remote case.
• Print processor — takes the spooled job and, for EMF jobs, plays back the records; it can add page-layout and job-control information to the data stream.

Monitor / port layer

• Language monitors — optionally modify the data stream (for example, Pjlmon.dll adds PJL commands) before handing off to the port monitor.
• Port monitors — direct the data stream to the correct port driver; Microsoft-supplied examples include the TCP/IP port monitor (TCPMON) and the WSD port monitor (WSDMON).
• Port driver / device — the serial, parallel, USB, or network port associated with the target printer's I/O port.

Driver components (v3 model)

• Printer graphics DLL — assists GDI in rendering and sends the rendered stream to the spooler.
• Printer interface DLL — provides the configuration UI and an interface the spooler calls for print-related events.
• Printer data files — used by Microsoft-supplied universal drivers.
• Microsoft universal drivers: Unidrv (the v3 print driver, driven by GPD minidriver files) and the PostScript driver Pscript5 (driven by PPD files).

How it works

When a Win32 GDI application prints, it calls GDI functions, which pass information to the graphics engine. The engine either spools drawing instructions as an EMF file for later playback by the EMF print processor, or works with the printer driver to render a printable image immediately. Spooler components can interpret EMF files and insert page-layout and job-control instructions. The spooler then sends the data stream toward the port driver for the target's I/O port.

Rendering location depends on driver type:

• A GDI-based (v3) driver renders during EMF playback under the control of the GDI rendering engine, which calls the driver for printer-specific drawing the engine cannot do itself.
• An XPSDrv driver processes the XPS spool file through a series of filter-pipeline stages and does not need GDI to render page images.

Print Ticket and Print Capabilities technologies communicate printer settings in a more application- and printer-compatible way. For v3 GDI drivers, the subsystem converts PrintTicket objects to equivalent DEVMODEW structures, so those drivers need not add PrintTicket support themselves; the conversion methods are ConvertPrintTicketToDevMode and ConvertDevModeToPrintTicket.

Data flow

Microsoft defines two primary print paths and two conversion paths so that any application type can print to any driver type.

Primary paths:

1. GDI print path (the Win32 path) — originates in a Win32 application using the GDI graphics API. 2. XPS print path — originates in a WPF application or via the XPS Print API.

Conversion paths:

• GDI-to-XPS conversion (MXDC) — the Microsoft XPS Document Converter converts GDI output into XPS when printing to an XPS device.
• XPS-to-GDI conversion (XGC) — converts XPS content into the GDI print path when printing to a GDI (v3) driver.

A representative end-to-end flow (GDI path, GDI driver, local printer) is: Application → GDI (Win32 plus graphics engine) → Winspool.drv → Spoolsv.exe → Router (Spoolss.dll) → print provider → print processor (EMF playback or rendering via the driver) → optional language monitor (for example, Pjlmon.dll) → port monitor (for example, TCPMON or WSDMON) → port driver → device.

Variations:

• XPS application to XPSDrv printer: the spooler passes the XPS spool file straight to the driver's filter pipeline for rendering and output.
• XPS application to GDI printer: the XPS spool file is converted through the XPS-to-GDI module (XGC), then follows the GDI path.
• GDI application to XPS printer: GDI commands are converted through the GDI-to-XPS module (MXDC) and sent down the XPS path.
• If a language monitor is installed, it receives the stream from the print processor, modifies it, and calls the port monitor; if not, the spooler calls the port monitor directly.

Operating system integration

The spooler runs as the Print Spooler service (Spoolsv.exe), started at OS startup. All spooler components run in user mode, while the GDI graphics engine has a kernel-mode component.

Point and Print integrates client and server printing. Since Windows Vista, driver-package installation using the driver store is the preferred method, adding integrity and signing checks on the client. v4 drivers run directly from the driver store, eliminating file collisions and improving install performance; setup uses INF files plus a v4 manifest (a *-manifest.ini file).

Group Policy and MDM integration is available through Policy CSP. For example, the ConfigureWindowsProtectedPrint policy uses the registry key Software\Policies\Microsoft\Windows NT\Printers\WPP and applies to Windows 11, version 24H2 (build 10.0.26100) and later. Printer-extension behavior is also policy-controllable. On the modern platform, multifunction devices expose print and fax over IPP and IPP Fax Out, and scan over WS-Scan or eSCL.

Relationship to standards

• IPP (Internet Printing Protocol) — the modern standardized client-to-printer communication; Windows implements it via the inbox Microsoft IPP Class Driver, and it is the protocol underlying Universal Print.
• XPS (XML Paper Specification) — the document and spool format for the XPS print path and XPSDrv drivers.
• PPD (PostScript Printer Description) and GPD (Generic Printer Description) — configuration file formats consumed by Pscript5 and Unidrv respectively; both remain valid in the v4 model (with added required directives).
• PostScript and PCL — page-description languages referenced by the driver models; the v4 model references XPS-to-PCL6 rendering filters and hardware/software copy handling.
• eSCL / WS-Scan — scanning standards used alongside IPP on multifunction devices.
• PWG standards — for example, the Port Monitor MIB (PWG 5107.1-2005) for TCP/IP auto-detection in v4 setup.
• IEEE 1284 — device ID string used as a fallback for naming and identifying Plug-and-Play printers.
• SNMP / WSD / USB Bidi — bidirectional communication transports (Bidi Schema) supported by the v4 connectivity stack.

Relationship to technologies

• GDI and the graphics engine — the classic rendering technology and the origin of the EMF spool format.
• WPF and the XPS Print API — modern application entry points that produce XPS spool files.
• Filter pipeline (PrintFilterPipelineSvc) — hosts the XPSDrv and v4 rendering filters; it is configured by a *-pipelineconfig.xml file.
• Print Ticket / Print Capabilities / DEVMODEW — the job- and device-settings model, with automatic conversion for legacy drivers.
• PrintConfig.dll — the v4 common configuration module that consolidates functionality formerly in the UnidrvUI and PS5UI core drivers; v4 decouples UI from driver configuration and can use JavaScript for advanced constraints, PrintTicket, and PrintCapabilities.
• mxdwdrv.dll — the default v4 render module; class drivers may alternatively specify unidrv.dll or pscript5.dll.
• Print Support Apps (PSA) and UWP device apps / printer extensions — customize preferences and notifications. Starting with the Windows 11 SDK (build 22000.1), PSA is the recommended method of developing UWP apps for printers, moving customization from the Win32 framework to the UWP framework.
• Universal Print — Microsoft's cloud print service that removes print servers and runs over IPP.

Relationship to manufacturers

Vendors historically shipped v3 and v4 drivers built on Microsoft's universal drivers by supplying GPD or PPD data files and, optionally, plug-ins (implementing interfaces such as IPrintOemPrintTicketProvider) and language or port monitors.

The v4 model narrows this: non-Microsoft port monitors and language monitors are not supported, and v4 leans on data files and JavaScript for extensibility while simplifying sharing by removing per-architecture driver management.

On the modern platform, manufacturers ship Mopria-certified printers that speak IPP, and device-experience customization moves to Print Support Apps delivered via the Store, so vendors no longer must rebuild per Windows SKU or architecture. The Mopria Alliance is the industry body that defines the IPP and eSCL conformance used here.

For signing, vendors submit drivers through Partner Center for validation and signing. Under the end-of-servicing plan, after January 15, 2026, new drivers for Windows 11 and later and Windows Server 2025 and later are signed only case-by-case, with documented exceptions: printers that cannot be Mopria-certified, submissions capped at Windows 10 or lower, and native ARM64 drivers.

Modern relevance

Microsoft's stated direction is to make driverless IPP printing the default. Windows Ready Print — defined by Microsoft as IPP printing plus eSCL scanning plus Universal Print — works without third-party drivers, across CPU architectures including ARM, and independent of driver-update breakage. Print Support Apps are a separate customization layer that works in combination with this platform rather than being part of its definition.

Windows protected print mode (WPP), introduced in Windows 11, version 24H2, hardens the path for security. It permits printing only to printers supported by the inbox Windows drivers (Mopria/IPP), disables loading of third-party drivers, defers spooler operations to a new spooler process, blocks module loading so that only Microsoft-signed IPP binaries load, and runs XPS rendering (PrintFilterPipelineSvc) as the user rather than as SYSTEM to limit the impact of memory-corruption bugs. Microsoft cites port-monitor-DLL abuse as an attack this design closes. Enabling WPP uninstalls third-party-driver printers and unsupported software printers (such as the legacy XPS Document Writer, Fax, and the OneNote desktop printer), which have documented reinstall or replacement paths.

The end-of-servicing timeline phases out legacy v3 and v4 driver servicing while keeping existing drivers installable and preserving security fixes during the OS support lifecycle.

Common misconceptions

• "The spooler runs in the kernel." The GDI graphics engine has a kernel-mode component, but all spooler components run in user mode.
• "Every job is fully rendered before spooling." GDI can spool device-independent EMF records and defer rendering to the print processor's playback; rendering can also be immediate. Both are supported.
• "v4 replaced v3 with a completely new rendering stack." v4 is described as a refinement of v3 that reuses XPSDrv rendering, GPD/PPD, autoconfiguration, and Bidi, adding new extensibility points.
• "XPS is Windows-only or obsolete legacy." XPS is a specified document format used as a spool and document format for XPSDrv, and it was supported on Windows XP and Windows Server 2003 via the WinFX runtime. It is de-emphasized under the modern IPP platform but is a real format, not merely a legacy spool artifact.
• "Driverless printing means no software at all." Customization still exists via Print Support Apps and, on the legacy platform, printer extensions and UWP device apps — the model moved from Win32 drivers to Store-delivered apps.
• "The IPP class driver and WPP work with any printer." They target Mopria-certified printers with IPP enabled; non-conforming devices may still need legacy driver-based printing.

Timeline

1. 1990s–2000s era

   GDI-based print path with EMF spooling and the v3 driver model (Unidrv/GPD, Pscript5/PPD); characterized by Microsoft as similar to the Windows Server 2003 print path.

2. Windows Vista era

   XPS print path and XPSDrv drivers introduced; XPS back-ported to Windows XP and Windows Server 2003 via the Microsoft WinFX Runtime Component 3.0; driver-store-based Point and Print packages introduced.

3. Windows 8 era

   v4 printer driver model introduced, optimized for UWP apps and simplified printer sharing.

4. Windows 10, version 21H2

   inbox support for Mopria printers over network and USB via the Microsoft IPP Class Driver.

5. Windows 11 SDK (build 22000.1)

   Print Support Apps (PSA) become the recommended method for developing printer apps.

6. September 2023

   Microsoft announces the legacy third-party printer driver end-of-servicing plan.

7. Windows 11, version 24H2 (build 10.0.26100)

   Windows protected print mode (WPP) ships.

8. January 15, 2026

   for Windows 11 and later and Windows Server 2025 and later, no new printer drivers are published to Windows Update (existing ones updated case-by-case).

9. July 1, 2026

   driver ranking order modified to always prefer the Windows IPP inbox class driver.

10. July 1, 2027

    except for security fixes, third-party printer driver updates are no longer allowed.