End of Servicing for Windows Printer Drivers — How Business Apps Should Prepare Their Report and Label Printing

“We replaced the PC and the paper and tray choices are different, even though it is the same printer.” “The saved print settings do not come back.” “The label printer has disappeared from the list.” Preparing for the end of printer driver servicing means making sure that changes like these do not stop the business.

The first thing to understand is that the driver end-of-servicing plan and enabling Windows protected print mode are two different things. Existing printing does not all stop the moment the plan’s dates pass. On the other hand, when the way a driver is chosen changes, or when Windows protected print mode is enabled, the settings and print destinations the app depended on are lost.¹²

This article is for developers who maintain Windows business apps in WinForms, WPF, and the like, and for administrators who deploy printers. It walks through what changes, what to investigate, what to fix, and how to verify, in that order. For how to choose a printing API or a PDF output method in the first place, see the previous article, Printing and PDF Output in Windows Business Apps.

The prerequisite environment is Windows 11 (24H2 or later for testing WPP), PowerShell 5.1 or later (the PrintManagement module), and C# (.NET 6 or later, or .NET Framework 4.x; System.Drawing.Printing / System.Printing). The difficulty is intermediate.

1. The Bottom Line First

Rather than rewriting all printing code across the board, first confirm whether the print destination survives, and then fix the places that depend on the driver.

The order of decisions has three stages.

If the app only draws with PrintDocument or FixedDocument, it is in principle a target for verification, not for rework. However, if the destination queue itself disappears under WPP and cannot be re-registered, printing fails even when the drawing code is fine. Another path is needed first.

If you want to start with the work itself, proceed in this order: take the list in 5.1 → judge the print destination with the tables in chapter 4 and 5.1 → check the dependencies in 5.2 through 5.5 → choose a path in chapter 6 → verify in chapter 7. Chapters 2 through 4 explain the background to the points where the decision is not obvious.

From here on, Windows protected print mode is abbreviated WPP. A “queue” is a print destination registered with Windows, and the “spooler” is the mechanism that receives print jobs and hands them on to the output destination.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (39 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. What Was Decided — A Three-Stage Timeline

2.1 What Ends Is Supply and Updates, Not a Blanket Shutdown of Existing Drivers

The primary source is “End of servicing plan for third-party printer drivers on Windows” on Microsoft Learn. The plan was announced in September 2023 and its dates were revised in May 2025. As of this writing, the plan is as follows.¹

Existing drivers can still be installed from Windows Update and from vendor-supplied installers, and Microsoft says it has no plans to disable v3/v4 driver functionality. In other words, this is a plan to phase out the supply and updating of drivers, not a plan to disable the drivers already installed on PCs in the field on that day.¹

flowchart TB
    accTitle: What changes and what does not with the end of driver servicing
    accDescr: The end of printer driver servicing by itself changes neither the entry point of the app's drawing API nor the existing drivers; only when a different driver is chosen on new installation or redetection are the paper list, proprietary features, and queue name the driver returned replaced, and the changes caused by enabling Windows protected print mode, including the removal of virtual printers, are a separate mechanism covered in chapter 4
    eos["End of printer driver servicing"]
    eos --> keep["What does not change"]
    eos --> cond["When a different driver is chosen on new installation or redetection"]
    cond --> change["What is replaced"]
    keep --> api["Drawing API entry point"]
    keep --> drv["Existing drivers"]
    change --> caps["Paper, trays, proprietary features"]
    change --> qname["Queue name"]

Figure 1: The end of servicing alone changes nothing; when a different driver is chosen, the information and names the driver provided are replaced. The changes caused by enabling WPP, including the removal of virtual printers, are a separate mechanism (chapter 4).

2.2 Drivers Change in the Field Mainly in Two Situations

Even though the plan does not stop existing drivers, the environment the app sees changes in the following situations.

When several driver packages match the same device, Windows assigns each a rank and selects the best one. The change on July 1, 2026 makes this selection prefer the IPP class driver. On devices for which the IPP class driver is not a candidate, the vendor package can continue to be selected.³¹

flowchart TB
    accTitle: Two paths by which drivers get replaced in the field
    accDescr: On devices the IPP class driver matches, ranking selects the IPP class driver on PC replacement, OS reinstallation, or printer redetection and the driver is replaced; when Windows protected print mode is enabled, printers on third-party drivers are removed, the driver is replaced on models that can be re-registered with Windows Ready Print, and the print destination is lost on models that cannot
    site["PC in the field"]
    site --> r1["PC replacement, OS reinstall, redetection"]
    site --> r2["Windows protected print mode enabled"]
    r1 --> rank["Preferred on devices the IPP class driver matches"]
    r2 --> del["Printers on third-party drivers removed"]
    rank --> swap["Driver is replaced"]
    del --> re{"Can it be re-registered with Ready Print?"}
    re -->|"Yes"| swap
    re -->|"No"| lost["Print destination is lost"]

Figure 2: Keeping the end-of-servicing plan and WPP apart lets you separate the situations where the driver changes from the situations where the print destination itself is lost.

It is also important here not to treat IPP support and Mopria certification as the same condition.

On a device that supports IPP without Mopria certification, the ranking change can replace the driver even if you do not use WPP. Conversely, a driver name of “Microsoft IPP Class Driver” by itself does not confirm that the printer can be used under WPP.¹⁴

flowchart TB
    accTitle: Matching the IPP class driver and Mopria certification are separate conditions
    accDescr: If the printer supports IPP, the ranking change can select the IPP class driver and replace the driver, while Mopria certification is a separate condition that decides whether the printer can be re-registered under Windows protected print mode, requiring IPP to be enabled and reachable on network-connected devices and IPP over USB mode on USB-connected devices
    printer["Printer"]
    printer --> q1{"Supports IPP?"}
    q1 -->|"Yes"| rank["Can be replaced"]
    q1 -->|"No"| keep["Stays on the vendor driver"]
    printer --> q2{"Mopria certified?"}
    q2 -->|"No"| ng["Cannot be re-registered under WPP"]
    q2 -->|"Yes"| q3{"USB connection?"}
    q3 -->|"No"| q5{"IPP enabled and reachable?"}
    q5 -->|"Yes"| ok["Can be re-registered under WPP"]
    q5 -->|"No"| ng
    q3 -->|"Yes"| q4{"IPP over USB mode?"}
    q4 -->|"Yes"| ok
    q4 -->|"No"| ng

Figure 3: The ranking effect is decided by IPP support; whether the printer survives under WPP is decided by Mopria certification plus IPP being enabled and reachable (IPP over USB mode for USB connections).

2.3 Driver Signing Has Exceptions, but Continuation Is Not Guaranteed

After January 15, 2026, drivers that meet any of the following conditions can have a signing exception submitted for case-by-case review.¹

• For printers that cannot obtain Mopria certification.
• Packages whose highest target OS is Windows 10 or earlier.
• Native ARM64 drivers.

Submissions are blocked by default for both WHQL and Attestation, and become a manual review with a justification document attached. Even when the conditions apply, there is no guarantee that the vendor will submit or that Microsoft will approve.⁵ Also, being able to obtain a signed driver and being able to use it in an environment with WPP enabled are two different things. Preparation for label and receipt printers is covered in chapter 6.

flowchart TB
    accTitle: Conditions under which driver signing is still allowed after January 15, 2026
    accDescr: Driver submissions from vendors are blocked by default, and only those meeting one of three conditions, printers that cannot obtain Mopria certification, packages whose highest target is Windows 10 or earlier, and native ARM64 drivers, can have an exception submitted for case-by-case review, which may lead to approval but does not guarantee signing
    submit["Vendor driver submission"]
    submit --> block["Blocked by default"]
    block --> c1["Model that cannot obtain Mopria certification"]
    block --> c2["Windows 10 or earlier as the highest target"]
    block --> c3["Native ARM64"]
    c1 --> apply["Exception can be requested"]
    c2 --> apply
    c3 --> apply
    apply --> review["Case-by-case review"]
    review --> maybe["May be approved (no guarantee)"]

Figure 4: Meeting the conditions only gets the driver into review; whether it is signed is not guaranteed.

3. How It Works — The Traditional Driver Path and Windows Ready Print

3.1 What Changes Is the Print Path Beyond the Drawing API

In traditional Windows printing, the app issues GDI or XPS drawing commands, the spooler receives the job, and the printer driver converts it into the printer’s language (PDL) and sends it. Both the GDI print path and the XPS print path sit on top of this structure.⁶

flowchart TB
    accTitle: The traditional driver path
    accDescr: The spooler running as SYSTEM spools the business app's GDI or XPS drawing commands, and a third-party v3 or v4 driver converts them into a proprietary PDL and sends them to the printer, inside the spooler process itself without driver isolation, or in a process separate from the spooler under shared or isolated mode
    app["Business app (GDI / XPS)"] --> spooler["Spooler (SYSTEM privileges)"]
    spooler --> iso{"Driver isolation"}
    iso -->|"None"| inproc["Third-party driver inside the spooler process"]
    iso -->|"Shared / Isolated"| host["Third-party driver in a separate process"]
    inproc --> pdl["Convert to proprietary PDL"]
    host --> pdl
    pdl --> printer["Printer"]

Figure 5: On the traditional path the process differs with isolation, but the structure in which third-party code inside the print stack handles the conversion to PDL is the same.

Its successor is Windows Ready Print. This is the collective name for printing over IPP (Internet Printing Protocol), scanning over eSCL, and Universal Print, and it requires no third-party driver. It is designed for Mopria certified printers, and its independence from the CPU architecture is another advantage.⁷

Windows 10 21H2 and later ship with the Microsoft IPP Class Driver, which handles Mopria-compliant printers over both network and USB.¹ Universal Print cloud queues use the inbox Universal Print Class Driver.⁸

flowchart TB
    accTitle: The Windows Ready Print path
    accDescr: The spooler receives the business app's drawing commands, and either the inbox Microsoft IPP Class Driver renders to PWG Raster or PDF on the client and sends it over IPP to a Mopria certified printer, or the inbox Universal Print Class Driver sends it over IPP over HTTPS to the Universal Print service; Windows protected print mode allows only this Windows Ready Print path
    app["Business app (GDI / XPS)"] --> spooler["Spooler"]
    spooler --> ipp["Microsoft IPP Class Driver"]
    ipp --> render["Render to PWG Raster / PDF"]
    render --> printer["Mopria certified printer (IPP)"]
    spooler --> up["Universal Print Class Driver"]
    up --> cloud["Universal Print service (IPP over HTTPS)"]
    wpp["Windows protected print mode"] -.->|"allows only the Ready Print path"| ipp
    wpp -.-> up

Figure 6: Windows Ready Print also goes through the spooler. What changes is that conversion and sending move from a third-party driver to the inbox class drivers.

IPP is an HTTP-based protocol, and it identifies a printer by a URI such as ipps://printer.example.com/ipp/print. The PDLs used for driverless printing are limited to a few formats based on public standards, such as PWG Raster and PDF, and the final document is rendered on the client side.⁹ With Universal Print, the spooler sends the job to the service over IPP over HTTPS.⁸

The entry point as seen from the app does not change. An app that draws with GDI or XPS calls the same APIs. What changes is the mechanism beyond that which returns the list of paper sizes and trays, provides proprietary features, and converts to PDL. That is why apps that depend on the information a driver returns or on proprietary settings are affected more than apps that only draw. For vendor-specific features, also check whether they are provided through a Print Support App (PSA).¹⁰

3.2 Check Print, Fax, and Scan Separately on Multifunction Devices

Whether a device can move to Windows Ready Print depends on the device having that function and implementing the corresponding protocol.¹

Do not conclude from Mopria print support alone that fax and scan can migrate too.

flowchart TB
    accTitle: Order for checking each function of a multifunction device separately
    accDescr: Pick the functions you use one at a time, check in order that the device has the function, that it supports the protocol in the table, and that it is in IPP over USB mode when USB-connected, and check the remaining functions separately instead of reusing the print result for fax or scan
    start["Pick one function you use"]
    start --> feature{"Does the device have the function?"}
    feature -->|"Yes"| protocol{"Supports the protocol in the table?"}
    feature -->|"No"| unmet["Condition for this function not met"]
    protocol -->|"Yes"| usb{"USB connection?"}
    protocol -->|"No"| unmet
    usb -->|"Yes"| mode{"IPP over USB mode?"}
    usb -->|"No"| checked["Condition for this function checked"]
    mode -->|"Yes"| checked
    mode -->|"No"| unmet
    checked --> next["Check the remaining functions separately"]
    unmet --> next

Figure 7: Check in the order of function availability, supported protocol, and the additional condition for the connection type. Do not reuse the print result for fax or scan.

3.3 The Background Is Print Stack Security

According to the Microsoft Learn explanation, printing-related bugs accounted for 9% of the MSRC (Microsoft Security Response Center) cases it tallied over the previous three years. The spooler runs with SYSTEM privileges, is broadly reachable from standard users, and loads third-party code on demand. Some old drivers are incompatible with modern mitigations such as CFG and CET, which makes it hard to apply mitigations that require every participating piece of code to support them.⁹

flowchart TB
    accTitle: Why mitigations cannot take effect as long as third-party drivers are loaded
    accDescr: The spooler running as SYSTEM loads third-party code, and because old drivers are incompatible with mitigations such as CFG and CET, mitigations that require every participant to support them cannot be applied to the spooler, making vulnerabilities easier to exploit
    sys["Spooler runs as SYSTEM"]
    load["Loads third-party code on demand"]
    old["Old drivers are incompatible with mitigations"]
    sys --> risk["Vulnerabilities are easier to exploit"]
    load --> nomit["Mitigations (CFG / CET / ACG) cannot be applied"]
    old --> nomit
    nomit --> risk

Figure 8: Mitigations only take effect once every participant supports them, so the spooler cannot be fully protected unless the drivers are removed.

Where a third-party driver runs depends on the printer driver isolation setting.¹¹

A driver that declares DriverIsolation=2 in its INF uses the shared process by default, and a driver that does not declare it runs inside the spooler process by default. Administrators can override this from the Print Management console or Group Policy. In every mode, however, third-party code still runs inside the print stack.¹¹ WPP is the operating mode that removes this dependency on third-party code.

flowchart TB
    accTitle: How the process a third-party driver runs in is decided
    accDescr: A driver that declares DriverIsolation=2 in its INF runs by default in a shared process separate from the spooler, a driver without the declaration runs by default inside the spooler process, and administrators can override this from the Print Management console or Group Policy to shared, inside the spooler process, or a separate dedicated process (isolated)
    inf{"INF declares DriverIsolation=2"}
    inf -->|"Yes"| shared["Runs in a separate shared process (default)"]
    inf -->|"No"| inproc["Runs inside the spooler process (default)"]
    admin["Overridden by administrator settings or policy"] -.-> shared
    admin -.-> inproc
    admin -.-> isolated["Runs in a dedicated separate process (isolated)"]

Figure 9: The isolation mode is decided by the INF declaration and administrator settings; old drivers without the declaration run inside the spooler process by default.

4. What Disappears Under Windows Protected Print Mode

4.1 WPP Is an Operating Mode That “Uses Only Windows Ready Print”

WPP was introduced in Windows 11 24H2. As of this writing it is disabled by default, and while disabled it places no restrictions on driver installation or printing features.¹²¹³ Keep separate the way it is enabled and who can turn it back off.

When it is enabled through Group Policy, the user cannot turn it off without contacting an administrator. The Intune OMA-URI is another path that applies the same ADMX-backed device policy. Assume that the user can turn it off from the Settings screen only when the user enabled it from the Settings screen.¹⁴²¹³

flowchart TB
    accTitle: Three paths for enabling Windows protected print mode
    accDescr: Windows protected print mode can be enabled from the Settings app, Group Policy, or an Intune OMA-URI; the user can turn it off from the Settings app only when the user enabled it there, and when it was distributed by Group Policy or an Intune policy it cannot be turned off without the administrator changing the policy
    s["Settings app (enabled by the user)"] --> wpp["Windows protected print mode enabled"]
    g["Group Policy"] --> wpp
    i["Intune (OMA-URI)"] --> wpp
    s -.->|"the user can turn it off in the Settings app"| off["Turned off"]
    g -.->|"the user cannot turn it off"| adm["Turning it off requires an administrator policy change"]
    i -.->|"the user cannot turn it off"| adm

Figure 10: There are three enabling paths, and the user can turn it off only when the user enabled it from the Settings app.

4.2 Queues That Survive, Queues That Disappear, and Queues That Must Be Re-Registered

The effect at enabling time depends not only on the printer itself but also on which driver it is currently registered with.²

flowchart TB
    accTitle: What happens to printers when Windows protected print mode is enabled
    accDescr: On enabling, printers installed with third-party drivers and unsupported virtual printers, the XPS Document Writer, and the fax virtual printer are removed; models that are Mopria certified and, for network connections, have IPP enabled and reachable or, for USB connections, are in IPP over USB mode can be re-registered with Windows Ready Print, and unsupported devices cannot be used while it is enabled
    on["WPP enabled"]
    on --> third["Printers on third-party drivers removed"]
    on --> soft["Unsupported virtual printers removed"]
    soft --> xps["XPS Document Writer and fax also removed"]
    third --> mopria{"Mopria certified?"}
    mopria -->|"Yes"| conn{"Connection type"}
    conn -->|"Network"| ipp{"IPP enabled and reachable?"}
    conn -->|"USB"| usb{"IPP over USB mode?"}
    ipp -->|"Yes"| re["Re-register with Windows Ready Print"]
    usb -->|"Yes"| re
    ipp -->|"No"| no["Unusable while enabled"]
    usb -->|"No"| no
    mopria -->|"No"| no

Figure 11: A queue on a vendor driver disappears once even if the printer is Mopria certified. Check the conditions for re-registration separately.

While WPP is enabled, the removed third-party drivers cannot be used. Also, turning WPP back off does not automatically return a printer that was reinstalled with Windows Ready Print to its original driver.²¹⁰

On the app side, the things to check are processing that assumes the paper sizes, trays, and proprietary features a vendor driver returns, port monitor DLL-style virtual printers, and the XPS Document Writer. Generating XPS files directly with XpsDocument and the like is different from printing to the virtual queue called XPS Document Writer, and is not affected by this removal.

4.3 Management and Spooler Internals Change Too

Under WPP, third-party binaries such as port monitor DLLs are no longer loaded. Module-loading APIs such as AddPrintProvidorW can no longer load new modules, and only the Microsoft-signed binaries needed for IPP are loaded. AddPrintProvidorW is the historical spelling in winspool.h; the Microsoft Learn explanation writes it as AddPrintProviderW.⁹

This restriction lets XPS rendering run with user privileges instead of SYSTEM, and the new spooler worker process uses a restricted token with privileges such as SeTcbPrivilege removed. Child process creation is prohibited, and CFG, CET, and ACG are enabled as well.⁹

flowchart TB
    accTitle: Changes to the spooler under Windows protected print mode
    accDescr: No longer loading third-party binaries makes it possible to restrict module loading, render XPS with user privileges, run worker processes with a restricted token, prohibit child process creation, and enable CFG, CET, and ACG
    nodrv["Third-party binaries are not loaded"]
    nodrv --> r["Restricted loading"]
    nodrv --> l["Reduced privileges"]
    nodrv --> m["Mitigations enabled"]
    r --> r2["Microsoft-signed binaries only"]
    l --> l2["User-privilege XPS, restricted token"]
    m --> m2["No child processes, CFG / CET / ACG"]

Figure 12: The mitigations that could not take effect in Figure 8 can be enabled only once third-party binaries are removed.

Point and Print keeps its IPP configuration but no longer installs third-party drivers. Provisioning procedures built on the assumption that “connecting to the print server distributes the driver” also need to be revisited.⁹

Whether WPP is currently enabled can be checked with the WinRT API Windows.Graphics.Printing.ProtectedPrint.WindowsProtectedPrintInfo.IsProtectedPrintEnabled on Windows 11 24H2 and later.¹⁵ The Group Policy setting is the value WindowsProtectedPrintGroupPolicyState under HKLM\Software\Policies\Microsoft\Windows NT\Printers\WPP.¹³

Note that a client with WPP enabled cannot manage a print server with WPP disabled from Print Management. Provide administrators with a separate management client that has WPP disabled.¹⁴

5. Taking Inventory of Existing Apps — The Four Places to Look

flowchart TB
    accTitle: The four places to inventory in a business app
    accDescr: In a business app's printing code, the four places, saving driver-specific settings, queue name dependencies (including those inside SDKs and libraries), dependencies on virtual printers not supported by WPP, and RAW sending to queues that do not survive WPP, are targets for rework, and code that only draws is a target for verification
    app["Business app printing code"]
    app --> deps["Inventory the four dependencies"]
    app --> d0["Drawing only"]
    deps --> d1["Saving driver-specific settings"]
    deps --> d2["Dependency on queue names"]
    deps --> d3["Dependency on virtual printers"]
    deps --> d4["RAW sending"]
    d2 -.-> d2n["Including inside SDKs"]
    d3 -.-> d3n["Those not supported by WPP"]
    d4 -.-> d4n["To queues that do not survive"]
    d1 --> fix["Rework"]
    d2 --> fix
    d3 --> fix
    d4 --> fix
    d0 --> verify["Verify"]

Figure 13: Only the four dependencies are targets for rework; code that only draws goes to verification.

5.1 First Take the Driver List in the Field and Judge the Print Destination

Whether rework is needed is decided after seeing what is installed in the field. Take the list of queues and drivers with PowerShell’s PrintManagement module. Listing with Get-Printer and Get-PrinterDriver does not require administrator rights, but the pnputil step in the second half does.¹⁶¹⁷

# For each queue, list the driver name, major version (3 = v3, 4 = v4), manufacturer, and INF file name
Get-Printer |
    Select-Object Name, DriverName, PortName,
        @{ Name = "DriverMajorVersion"; Expression = { (Get-PrinterDriver -Name $_.DriverName).MajorVersion } },
        @{ Name = "Manufacturer"; Expression = { (Get-PrinterDriver -Name $_.DriverName).Manufacturer } },
        @{ Name = "InfName"; Expression = { Split-Path -Leaf (Get-PrinterDriver -Name $_.DriverName).InfPath } } |
    Sort-Object DriverName |
    Format-Table -AutoSize

# Enumerate only third-party driver packages, with the published name (oemN.inf), original INF name, and provider (requires administrator rights)
pnputil /enum-drivers /class Printer

MajorVersion distinguishes v3 from v4.¹⁸ However, the v3/v4 distinction and the inbox/third-party distinction are separate. Classify as follows.

InfPath from Get-PrinterDriver is the path to the INF inside the driver store and is not guaranteed to return the published oemN.inf name. Match the published name, original INF name, and provider returned by pnputil /enum-drivers against the file name of InfPath and Manufacturer. pnputil /enum-drivers lists only third-party packages; inbox packages do not appear in the list.¹⁹¹⁷

flowchart TB
    accTitle: Procedure for inventorying the printers in the field
    accDescr: Take the list of queues and drivers with PowerShell, and by DriverName and by matching Manufacturer against the third-party package list from pnputil divide them into queues on the IPP class driver, Universal Print queues (WPP compatible), queues on other inbox drivers (XPS and fax removed, Generic / Text Only cannot be assumed to survive, Microsoft Print to PDF is not listed for removal so it is judged individually), and queues on vendor drivers (candidates for replacement); for queues on the IPP class driver separately confirm Mopria certification, IPP enabled and reachable for network connections, and IPP over USB mode for USB connections, and then match every queue against the queues the app's settings and printing code point to
    list["Take the list with Get-Printer / Get-PrinterDriver"]
    list --> cls{"DriverName and provider"}
    cls -->|"IPP Class"| ipp["Queue on the IPP class driver"]
    cls -->|"Universal Print Class"| up["Universal Print queue"]
    cls -->|"Other inbox"| inbox["Judge individually with the chapter 4 table"]
    cls -->|"Vendor"| vendor["Candidate for replacement"]
    ipp --> mop["Check Mopria, IPP reachability, USB"]
    mop --> match["Match against the app's settings and code"]
    up --> match
    inbox --> match
    vendor --> match
    match --> judge["Sort with the decision table"]

Figure 14: Taking the list and sorting by name needs no administrator rights; matching the provider requires administrator rights for pnputil.

Match this list against the queues referenced by the app’s settings, printing code, and the SDKs it uses. If you record the driver, Mopria certification, connection type, IPP reachability, and USB operating mode for each customer site, you can make the judgment with the table in chapter 4.

If the print destination does not survive WPP and cannot be re-registered, either provide the alternative path in chapter 6 or decide not to use WPP before inventorying the code. If the device can be affected by the IPP ranking change even without WPP, continue with 5.2 onward. If you do not use WPP and driver replacement has no effect, the decision is to keep operating on the current path.

To check the driver name from inside the app, read PrintQueue.QueueDriver.Name with WPF’s System.Printing.²⁰

using System.Printing;

// From an administration tool or desktop app, list the driver name of each queue
using var server = new LocalPrintServer();
foreach (PrintQueue queue in server.GetPrintQueues(
    new[] { EnumeratedPrintQueueTypes.Local, EnumeratedPrintQueueTypes.Connections }))
{
    Console.WriteLine($"{queue.Name}\t{queue.QueueDriver?.Name}\t{queue.QueuePort?.Name}");
}

However, the System.Printing namespace does not support use inside a Windows service. If you print from a resident service, put this diagnostic in the administration tool instead.²¹ For the constraints on printing from a service, see How to Build and Operate Windows Services and chapter 7 of the previous article.

5.2 Check 1: Are Driver-Specific Settings Saved and Restored?

The hardest thing to find is saved print settings. The reason they break differs with how they are saved.

DEVMODE can carry private data after its public members, with its size given by dmDriverExtra. Windows validates only the public part, and corrupt private data can crash the driver in the app’s or the spooler’s process.²²

flowchart TB
    accTitle: The public and private parts of DEVMODE
    accDescr: The DEVMODE structure carries driver-defined private data indicated by dmDriverExtra after its public members; only the public part is validated by Windows and the private part can be interpreted only by that driver, so saving it whole loses its meaning when the driver changes
    dm["DEVMODE structure"]
    dm --> pub["Public part (dmSize)"]
    dm --> priv["Private part (dmDriverExtra)"]
    pub --> chk["Validated by Windows"]
    priv --> only["Interpreted only by that driver"]
    only --> lost["Loses its meaning when the driver changes"]

Figure 15: Of a setting saved whole, the part that breaks is the private part.

A PrinterSettings that received its settings through SetHdevmode copies this private area internally.²³ The .NET Framework version of PrinterSettings has the Serializable attribute, and binary serialization includes private fields by default, so saving the whole object carries the same dependency.²⁴²⁵

The .NET version of PrinterSettings, on the other hand, has no Serializable attribute, and an implementation that saves the public properties individually in its own format does not save the native DEVMODE buffer or the dmDriverExtra area.²⁴ What to watch for in this case is driver-dependent values.

flowchart TB
    accTitle: Saving DEVMODE and saving managed values break differently
    accDescr: An implementation that saves the DEVMODE buffer whole and one that serializes a PrinterSettings whole after receiving the private area through SetHdevmode carry the private part with them and lose their meaning when the driver changes; an implementation that saves public property values carries Custom or vendor-specific paper and tray numbers that are values against the vendor driver's list and are not guaranteed to mean the same under the IPP class driver; both are replaced by a design that saves only the intent
    a["Save DEVMODE whole"]
    a --> a1["Carries the private part along"]
    s["Save whole after SetHdevmode"] --> a1
    a1 --> a2["Loses its meaning when the driver changes"]
    b["Save public property values"]
    b --> b1["Carries custom paper and tray numbers along"]
    b1 --> b2["No guarantee of the same meaning on the new driver"]
    a2 --> c["Both move to saving only the intent"]
    b2 --> c

Figure 16: Saving the whole object after SetHdevmode falls on the private-part side; the failure modes differ, but both carry driver state along.

If RawKind represents a standard PaperKind or PaperSourceKind, it keeps its meaning when the driver changes. What is not guaranteed is that Custom or vendor-specific numbers point to the same paper or tray on a different driver. Do not treat standard values as breaking across the board.²⁶²⁷

flowchart TB
    accTitle: Which saved paper and tray values break
    accDescr: Among RawKind values, those that correspond to standard paper sizes (PaperKind) such as A4 or standard paper sources (PaperSourceKind) such as Upper and Lower keep their meaning when the driver changes, while Custom and vendor-specific values are numbers against the vendor driver's list and the IPP class driver is not guaranteed to interpret them as the same paper or tray
    raw["Saved RawKind"]
    raw --> std["Standard values (PaperKind etc.)"]
    raw --> cus["Custom and vendor-specific values"]
    std --> keep["Keeps its meaning when the driver changes"]
    cus --> lost["No guarantee of the same paper or tray"]

Figure 17: What breaks is not the standard values but the custom values against the vendor driver’s list.

A PrintTicket also defines its public keywords in the psk namespace but can contain device-specific private extensions. The rule is that third-party elements belong in a namespace clearly associated with that third party. If a vendor namespace appears in the saved XML, check it as a driver-specific setting.²⁸²⁹

Remedy: Save Only the “Intent”

Keep the intent, meaning the choice of paper size, orientation, duplex, copies, and tray, in your own settings file using public keywords. Instead of carrying the driver’s internal state forward, match it against the current capabilities immediately before printing.

In WPF, get the capabilities with PrintQueue.GetPrintCapabilities, express the request as a PrintTicket, and pass it to MergeAndValidatePrintTicket.³⁰ The thing to watch here is that an unsupported request does not necessarily produce an error. The driver may resolve the conflict and return a valid ticket, usually with the setting replaced by a default or similar.

If ValidationResult.ConflictStatus is ConflictResolved, compare the duplex and tray in ValidatedPrintTicket with the request, log the difference, and notify the user.³¹

flowchart TB
    accTitle: A design that saves only the intent and checks it against capabilities immediately before printing
    accDescr: The settings file holds only the intent for paper, orientation, duplex, copies, and tray in public keywords; immediately before printing, get the current printer's capabilities with GetPrintCapabilities, pass through MergeAndValidatePrintTicket, print as is if ConflictStatus is NoConflict, and if it is ConflictResolved compare the replaced items with the request and send them to the log and a notification
    cfg["Settings file: intent only (paper, orientation, duplex, copies)"]
    cfg --> caps["GetPrintCapabilities immediately before printing"]
    caps --> merge["MergeAndValidatePrintTicket"]
    merge --> st{"ConflictStatus"}
    st -->|"NoConflict"| print["Print"]
    st -->|"ConflictResolved"| tell["Log and notify the difference from the request"]

Figure 18: Save the intent of the settings and validate it against the current capabilities at print time. Do not silently use a replaced setting; check the difference.

In WinForms, reselect the paper from PrinterSettings.PaperSizes by Kind or dimensions rather than by name. Paper sources from PaperSources can be reused when they are unique standard values such as Upper or Lower, but several proprietary trays can come back lumped together as PaperSourceKind.Custom. And PaperSource carries no paper dimensions. Do not identify a proprietary tray by Kind alone; either remap it explicitly to the current capabilities or have the user choose again.²⁷

5.3 Check 2: Is There a Dependency on Printer or Queue Names?

The previous article recommended keeping the printer name in a settings file. What is added here is the premise that there is no guarantee a queue with the same name is created after a driver replacement or redetection. A setting that points to the old queue name loses its print destination as it is.

The places to check are three: the settings file, names hard-coded in the code, and the internals of SDKs and report libraries. Even when your own code has no fixed name, a vendor SDK may call a specific queue or driver internally. Match the SDK documentation against the list from 5.1.

flowchart TB
    accTitle: Three places where a queue name dependency can hide
    accDescr: A queue name dependency can hide in three places, a fixed name in the settings file, a fixed name hard-coded in the code, and the queue or driver a vendor SDK or report library calls internally; the first two are found by searching the code and settings, the last by the SDK documentation and the list from 5.1
    dep["Dependency on queue names"]
    dep --> cfg["Fixed name in the settings file"]
    dep --> code["Fixed name hard-coded in the code"]
    dep --> sdk["Fixed inside the SDK or library"]
    cfg --> grep["Find by searching the code and settings"]
    code --> grep
    sdk --> doc["Confirm with the SDK documentation and the 5.1 list"]

Figure 19: Even when your own code has no queue name, a dependency may remain inside an SDK or library.

The remedy is to check at startup that the configured name exists in PrinterSettings.InstalledPrinters, and if it is not found, log it and notify the user. Also make it possible to reselect the print destination from the settings screen.

Do not fall back silently to the default printer. It hides a slip coming out of another department’s printer as a normal print.

flowchart TB
    accTitle: Validating the printer name at startup
    accDescr: At startup, check whether the printer name in the settings file exists in InstalledPrinters; if it does, print; if it does not, log it, notify the user, and have them choose again, and do not fall back silently to the default printer
    start["Startup: printer name from settings"]
    start --> exists{"Exists in InstalledPrinters?"}
    exists -->|"Yes"| print["Print to that queue"]
    exists -->|"No"| log["Log and notify the user"]
    log --> pick["Choose again on the settings screen"]
    exists -.->|"do not do this"| silent["Fall back silently to the default printer"]

Figure 20: An implementation that silently prints to another printer when the destination is not found creates the failure that takes longest to discover.

5.4 Check 3: Is a Virtual Printer Used to Generate Files?

A report archive that prints to a third-party PDF printer and watches the output folder, or processing that creates intermediate files with the XPS Document Writer, stops working when the queue it uses is removed by WPP.

However, what is removed is software printers not supported by WPP. Do not confuse unsupported products such as port monitor DLL-style ones with products that have been updated for WPP support, such as OneNote. Step 3 in chapter 7 confirms whether the queue you actually use is a removal target.²

If what you want is a PDF, then as explained in chapter 5 of the previous article, moving to a setup that generates it directly with a PDF library is the design least dependent on changes in the print stack.

5.5 Check 4: Does RAW Sending Go Through a Queue That WPP Removes?

RAW sending is the method of pushing printer-language data through the spooler with OpenPrinter → StartDocPrinter (data type “RAW”) → WritePrinter → EndDocPrinter. The document must fully describe the print settings in the hardware’s language, and the DEVMODE settings are not used.³²³³

It is the standard approach for labels and receipts, but RAW sending is not “direct communication that bypasses the spooler”. Even if the driver is effectively used only as a pass-through to the port, that pass-through is lost when WPP removes the queue.

flowchart TB
    accTitle: The RAW sending path and where WPP removes it
    accDescr: The app pushes printer-language data into the spooler with OpenPrinter, StartDocPrinter, and WritePrinter, and a queue that does not survive WPP (such as a queue on a vendor driver) acts as the pass-through to the port and on to the printer, so when WPP removes that queue the pass-through is gone
    app["App: StartDocPrinter (RAW), WritePrinter"]
    app --> spooler["Spooler"]
    spooler --> queue["Queue that does not survive WPP (pass-through)"]
    queue --> port["Port"]
    port --> printer["Label or receipt printer"]
    wpp["WPP enabled"] -.->|"queue disappears"| queue

Figure 21: RAW sending uses the driver only as a pass-through, but the pass-through itself disappears.

What to check is which combination of queue, driver, and port you are sending to. Not only queues on vendor drivers but also inbox drivers for physical printers other than the IPP class driver, such as Generic / Text Only, cannot be assumed to survive. Anything confirmed to disappear in the chapter 7 removal list needs another path in the same way.¹³

Also, Microsoft Learn does not state that a proprietary PDL can be sent RAW to a queue on the IPP class driver. Because it depends on the PDLs the printer’s IPP implementation accepts, do not conclude that “switching to IPP lets the same RAW data through”.

6. An Escape Route for Label and Receipt Printers

KomuraSoft recommends having at least one output path for labels and receipts that does not depend on the spooler.

Even when a printer falls under the signing exception in chapter 2, continued supply of the vendor driver and its use under WPP are not guaranteed.¹ Microsoft’s troubleshooting guidance also records a case in which USB-connected receipt and label printers stopped printing after a 2021 update and the problem was resolved by a Known Issue Rollback.³⁴ Knowing your output paths separately is the preparation.

For TCP reconnection design, the thinking in Serial Communication App Pitfalls applies. For choosing a USB method, see How to Work with USB Devices from a Windows App. IPP is disabled by default on some printers and must be enabled.⁴

The name “SDK” alone does not tell you whether a path is independent. Use the SDK documentation and the list from 5.1 to confirm whether it talks to the device directly or ends up calling a Windows queue.

When a Windows queue is used, Universal Print is on the WPP-compatible side, but it too goes through the spooler. A queue that is neither the IPP class driver nor Universal Print stops under WPP if it is a third-party driver, XPS, or fax, and an inbox queue not listed for removal, such as Microsoft Print to PDF, is judged individually. “WPP compatible” and “spooler independent” are different classifications.

flowchart TB
    accTitle: Flow for deciding whether an output path depends on the spooler
    accDescr: If the candidate path sends to a Windows print queue, then a queue on the IPP class driver whose printer is Mopria certified and, for network connections, has IPP enabled and reachable or, for USB connections, is in IPP over USB mode, and a Universal Print queue as part of Windows Ready Print, depend on the spooler but are WPP compatible; queues on non-Mopria-certified devices or third-party drivers, and queues removed per the chapter 4 table such as the XPS Document Writer and fax, can stop under WPP; inbox queues not listed for removal such as Microsoft Print to PDF are judged individually as in 5.1; if it does not send to a queue, an SDK that internally calls a queue or driver returns to the same judgment, while an SDK that does not or a path that sends directly to the device is an escape route that does not depend on the spooler
    route["Candidate output path"]
    route --> q1{"Sends to a Windows print queue?"}
    q1 -->|"Yes"| q4{"Queue on the IPP class driver?"}
    q4 -->|"Yes"| q5{"Mopria certified?"}
    q5 -->|"Yes"| q9{"IPP reachable? (USB: over USB)"}
    q9 -->|"Yes"| depok["Depends, but WPP compatible"]
    q9 -->|"No"| dep["Depends, and can stop under WPP"]
    q5 -->|"No"| dep
    q4 -->|"No"| q6{"Universal Print queue?"}
    q6 -->|"Yes"| depok
    q6 -->|"No"| q7{"Removed per the chapter 4 table?"}
    q7 -->|"Yes (third-party driver, XPS, fax)"| dep
    q7 -->|"No (Print to PDF etc.)"| indiv["Judge individually (5.1)"]
    q1 -->|"No"| q2{"Goes through a vendor SDK?"}
    q2 -->|"Yes"| q3{"Calls a queue or driver internally?"}
    chk["Check: SDK docs and the 5.1 list"] -.-> q3
    q3 -->|"Yes"| q4
    q3 -->|"No"| indep["Escape route with no dependency"]
    q2 -->|"No"| indep

Figure 22: It comes down to which queue the path ultimately goes through; apart from a queue on the IPP class driver for a Mopria certified device and a Universal Print queue, everything except inbox queues not listed for removal can stop under WPP.

7. Verification Procedure — With and Without WPP

First confirm the branch of the verification depending on whether you use WPP or not. In both cases, keep the output from before the change and verify with the print destinations you actually use.

flowchart TB
    accTitle: Print verification procedure split by whether WPP is used
    accDescr: Reproduce all queues on a test machine and save the output from before the change; if WPP is used, enable it, record the removed queues, compare the output after re-registering compatible devices, and check the alternative path for incompatible devices; if it is not used, redetect physical devices subject to the IPP ranking change with WPP disabled and compare the output, and for everything else confirm printing on the actual queues
    prepare["Reproduce and record all queues"]
    prepare --> baseline["Save the print results from before the change"]
    baseline --> use{"Use WPP?"}
    use -->|"Yes"| enable["Enable and record the removed queues"]
    enable --> compatible["Re-register compatible devices as needed"]
    compatible --> compare["Compare with the same prints as before"]
    enable --> alternate["Check incompatible devices on the alternative path"]
    use -->|"No"| physical{"Physical device subject to IPP ranking change?"}
    physical -->|"Yes"| redetect["Remove and redetect with WPP disabled"]
    redetect --> compare
    physical -->|"No"| existing["Confirm printing on the actual queues"]
    compare --> finish["Record the results and restore the test machine"]
    alternate --> finish
    existing --> finish

Figure 23: The output from before the change is the common baseline, and only environments that use WPP enable it. Environments that do not use it check the IPP ranking change and printing on the actual queues.

7.1 Common Preparation: Reproduce Every Print Destination on a Test Machine, Not in Production

Use a PC running Windows 11 24H2 or later for verification, and do not do it on a production PC. For network connections, a VM that can reach the same printers is enough. To evaluate USB re-registration or direct communication, use a physical test machine, unless the VM can pass through the same USB interface.

Regardless of whether WPP is used, steps 1 and 2 below preserve the state before the change.

1. Reproduce every queue the app uses in the field. Install not only the physical printers on vendor drivers but also third-party PDF virtual printers and inbox queues such as Generic / Text Only, in the same configuration. Record the driver names and versions with the script from 5.1. The removal diff can only judge queues that exist on the test machine.
2. Run through the printing features and save the output. Check the paper, tray, duplex, and copies settings screens, the printing of each report, PDF output, and label printing, to create a baseline for later comparison.

flowchart TB
    accTitle: Queues to reproduce on the test machine
    accDescr: Of the queues the app uses as found by the 5.1 inventory, reproduce the physical printers on vendor drivers, the virtual printers such as third-party PDF, and the queues on inbox drivers such as Generic / Text Only, all on the test machine in the same configuration as the field, showing that the removal list in step 3 can only judge queues that exist on the test machine
    inv["5.1 inventory: queues the app uses"]
    inv --> phys["Physical printers (vendor drivers)"]
    inv --> virt["Virtual printers (third-party PDF etc.)"]
    inv --> inbox["Inbox drivers (Generic / Text Only etc.)"]
    phys --> vm["Reproduce on the test machine in the same configuration"]
    virt --> vm
    inbox --> vm
    vm --> judge["Judge survival with the step 3 removal list"]
    note["Missing queues do not appear in the removal diff"] -.-> judge

Figure 24: A queue absent from the test machine does not appear in the removal diff, so first reproduce every queue the inventory found.

7.2 Environments That Use WPP: Enable It and Verify, Including the Print Destinations That Disappeared

After steps 1 and 2, proceed in the following order.

3. Enable WPP and record the queues that are removed. Choosing “Set up” under “Windows protected print mode” in “Printers & scanners” in the Settings app shows the removal targets in a dialog.² When enabling through Group Policy, no dialog appears, so save the Get-Printer result before applying the policy and restart the test machine after applying it. Confirm it is enabled with IsProtectedPrintEnabled or the Settings screen, then take the list again and record the diff.¹⁴
4. Reinstall the removed compatible printers. Reinstall them with Windows Ready Print and confirm with the 5.1 script that the physical printer’s DriverName has changed to Microsoft IPP Class Driver.
5. Repeat the same prints and compare with before the change. Check the choices on the settings screens, the restoration of saved settings, and the loss of print destinations due to queue name changes. Also match the margins, fonts, and rules of the output against the output from step 2.
6. Print incompatible devices through the alternative path from chapter 6. Reproduce the state in which “the printer is not in the list” and confirm that output still works. Not only the code you fixed but also the path you provided is a verification target.

7.3 Environments That Do Not Use WPP: Verify the Change in Driver Selection Without Enabling It

In an environment where you have decided not to use WPP, do not perform steps 3 and 4. Enabling WPP removes whole queues, which hides the effect of ranking alone.

7.4 Restore After Verification and Prepare the Provisioning Procedure

A test machine on which WPP was enabled in the local Settings app can be restored with “Turn off”. If it was applied from Group Policy or Intune, an administrator-side policy change is required, so prepare a restore procedure that matches the enabling path.²¹³

Turning WPP back off leaves the printers reinstalled with Windows Ready Print as they are. Printers that were incompatible are reinstalled manually.²¹⁰

For provisioning, build the WPP policy and the printer re-registration procedure into the distribution mechanism laid out in From Group Policy to Intune. Third-party driver distribution through Point and Print has required administrator credentials by default since KB5005652 in 2021,³⁴ and under WPP the distribution itself no longer happens.⁹ In environments that use WPP, replace procedures that depend on driver distribution with this policy application and re-registration procedure.

flowchart TB
    accTitle: Revising the provisioning procedure
    accDescr: The procedure that distributed third-party drivers through Point and Print is dropped because administrator credentials have been required since 2021 and under WPP the distribution itself no longer happens, and in its place the WPP policy (Group Policy or OMA-URI) and the printer re-registration procedure are built into the distribution mechanism
    old["Distribute third-party drivers through Point and Print"]
    old --> why1["Administrator credentials required since 2021"]
    old --> why2["No distribution at all under WPP"]
    why1 --> drop["Drop from the procedure"]
    why2 --> drop
    drop --> add["Build in the WPP policy and re-registration procedure"]

Figure 25: The procedure for distributing drivers is replaced by a procedure for distributing the WPP policy and printer re-registration.

8. Summary

The required response is decided in the order “does the print destination survive?” → “what does the code depend on?” → “under which conditions do we verify?”.

Fixing one thing is not the end. After fixing the settings, go on to check queue names, virtual printers, and RAW sending, and finally confirm the output as in chapter 7. On devices where the IPP ranking change can happen even without WPP, you need the dependency inventory and the redetection verification with WPP left disabled.

flowchart TB
    accTitle: Decision tree for whether to fix or only verify
    accDescr: First decide whether the destination queue survives WPP (a Universal Print cloud queue or a WPP-supported virtual printer) or whether the physical printer can be re-registered with Windows Ready Print; if not, choose between providing another path and not using WPP; if the device supports IPP and can be replaced by the ranking change, check in order for saving driver-specific settings, dependencies on queue names or virtual printers (including inside SDKs and libraries), and RAW sending, fixing each that applies before moving on; finally, environments that use WPP go to the chapter 7 WPP-enabled verification, environments that do not send physical IPP-capable devices to the redetection verification with WPP disabled and cloud or virtual queues to actual output checks, and if WPP is not used and replacement has no effect, keep operating on the current path
    q0{"Does the queue survive WPP or can it be re-registered?"}
    q0 -->|"No"| alt{"What to do"}
    alt -->|"Provide another path"| qi{"Supports IPP and can be replaced?"}
    alt -->|"Do not use WPP"| qi2{"Supports IPP and can be replaced?"}
    qi -->|"Yes"| q1{"Are driver-specific settings saved?"}
    qi -->|"No"| verify["Verify only (chapter 7)"]
    qi2 -->|"Yes"| q1
    qi2 -->|"No"| keep["Keep operating on the current path"]
    q0 -->|"Yes"| q1
    q1 -->|"Yes"| fix1["Fix (5.2)"]
    fix1 --> q2{"Depends on queue names or virtual printers?"}
    sdk["Including dependencies inside SDKs and libraries"] -.-> q2
    q1 -->|"No"| q2
    q2 -->|"Yes"| fix2["Fix (5.3, 5.4)"]
    fix2 --> q3{"Sends RAW to a queue that does not survive WPP?"}
    q2 -->|"No"| q3
    q3 -->|"Yes"| fix3["Provide a pass-through (chapter 6)"]
    fix3 --> vq{"Use WPP?"}
    q3 -->|"No"| vq
    vq -->|"Yes"| verify
    vq -->|"No"| pq{"Physical IPP-capable device?"}
    pq -->|"Yes"| redetect["Redetection verification without WPP (7.3)"]
    pq -->|"No"| outchk["Confirm output on the actual queues"]

Figure 26: First decide whether the queue survives WPP; for code dependencies, move on to the next check even after fixing one, and verify the fixed path at the end. If WPP is not used, verify not with the chapter 7 WPP enablement but by redetecting physical IPP-capable devices with WPP disabled and by actual output on cloud and virtual queues.

Put the Preparation Deadline on Your Own Rollout Plan, Not on Microsoft’s Dates

WPP is said to become enabled by default in the future, but no date is given.¹⁰ Put the preparation deadline before you enable WPP yourself, or before you roll out the Windows 11 24H2 or later feature update to the field. July 1, 2027 is a milestone on the driver supply side, not a deadline for business apps.¹

flowchart TB
    accTitle: Where to put the preparation deadline on the business app side
    accDescr: Take the list and inventory now, finish the path changes and verification by your own deadline, meaning before you enable WPP yourself or before you roll out the 24H2 or later feature update; the driver update stop on July 1, 2027 is a supply-side milestone, not the preparation deadline, and the goal is to reach a state unaffected by the default enablement of WPP, whose timing is undetermined, whenever it comes
    now["Now: take the list and inventory"]
    now --> prep["Path changes and verification"]
    prep --> deadline["Deadline: before enabling WPP yourself / before rolling out the feature update"]
    deadline --> fine["Unaffected when WPP becomes enabled by default (timing undetermined)"]
    ms["July 1, 2027: driver updates stop"] -.->|"supply-side milestone, not a deadline"| prep

Figure 27: Put the deadline on your own rollout plan, and do not make Microsoft’s milestone dates your cutoff.

Start by taking the list at each customer site and understanding the dependencies on settings, print destinations, and output paths. Generate PDFs directly, and keep one path for labels and receipts that is independent of the print stack. Then verify printing under the actual rollout conditions.

Environments that stay on Windows 10 are outside the scope of this plan, but support for Windows 10 (22H2) on the regular channel ended in October 2025. Enterprise LTSC and IoT Enterprise LTSC have different end dates per edition, so check the lifecycle. For decisions involving ESU and LTSC, see Practical Options After Windows 10 End of Support, and for industrial PCs, Which Windows Should You Put on an Industrial PC?. Preparation for printing is not complete until you redo the chapter 7 verification on the Windows 11 you migrate to.

Related Articles

• Printing and PDF Output in Windows Business Apps — Choosing Between System.Drawing.Printing, WPF, and Report Libraries
• How to Build Excel Report Output - COM / Open XML / Templates
• How to Build and Operate Windows Services — From Choosing Between Task Scheduler and Services to Turning a BackgroundService into a Windows Service
• How to Work with USB Devices from a Windows App — Choosing Between Virtual COM, HID, and WinUSB
• Serial Communication App Pitfalls - Through Reconnection and Log Design
• From Group Policy to Intune — A Device-Management Migration Guide for Small and Medium Businesses
• Practical Options After Windows 10 End of Support — A Decision Table for ESU, LTSC, and Replacement

Related Consulting Areas

KomuraSoft LLC handles inventorying the printer driver dependencies of business apps with report and label printing, reworking print paths (direct PDF generation, direct control of label printers), and designing verification plans that assume Windows protected print mode.

• Technical Consulting & Design Review
• Windows App Development
• Contact

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Will the printers and apps that work today suddenly stop printing once July 2026 or July 2027 passes?

No. Microsoft's plan is a phased cutoff on the supply side: new third-party drivers are no longer published to Windows Update, driver ranking prefers the IPP class driver, and updates are no longer accepted. The plan explicitly states that it does not disable existing drivers, and existing drivers can still be installed from vendor-supplied installers. The dangerous situations are, on devices the IPP class driver matches, the moment a PC is replaced or the OS is reinstalled and the driver is automatically replaced by the IPP class driver, and the moment Windows protected print mode is enabled.

Is Windows protected print mode enabled by default?

As of this writing (September 2026) it is disabled by default, and it is enabled from the Settings app, Group Policy, or Intune. However, Microsoft's FAQ states clearly that it will be enabled by default at some future point. No date is given, so the preparation is to reach a state where enabling it causes no trouble before that happens.

What happens to label printers and receipt printers?

Printers that cannot obtain Mopria certification are listed among the conditions under which driver signing continues to be allowed as an exception after January 15, 2026. So a vendor driver may remain available for the time being, but in an environment where Windows protected print mode is enabled, printers that use third-party drivers are uninstalled, so they cannot be used as they are. Having a vendor SDK that talks to the device directly over TCP, USB, or serial, or a path that drives the printer by sending its printer language directly, isolates you from changes in the Print Spooler. An SDK that internally calls a Windows queue or driver stops just the same when the third-party driver disappears, so it is not an escape route.

Can the app's printing code stay on PrintDocument?

The GDI print path and the XPS print path remain, and Microsoft states clearly that it has no plans to disable v3/v4 driver functionality. An app that only draws with PrintDocument or FixedDocument is something to verify, not something to fix. What needs fixing is code that saves and restores driver-specific settings (the private part of DEVMODE or a private namespace in a PrintTicket), code that depends on a specific queue name or virtual printer name (including what a vendor SDK or report library calls internally), and code that sends RAW data through the spooler to a queue that does not survive WPP (such as a queue on a vendor driver). However, if the destination printer itself is a model that cannot be re-registered with Windows Ready Print, the whole queue disappears under Windows protected print mode even when the code only draws, so providing another path comes first.

Where should I start?

Start by taking a list of the printers and drivers at each customer site. PowerShell's Get-Printer and Get-PrinterDriver tell you which queue uses which driver (v3 or v4, or the IPP class driver) without administrator rights. Next, match that list against the queues the app names explicitly, saves settings for, or sends RAW data to, and sort them into 'leave as is', 'verify', and 'change the path' using the decision table in this article.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.