dotnet/wpf · error · PrintQueueException

PrintSystemException.PrintQueue.XpsDeviceQuery

Error message

PrintSystemException.PrintQueue.XpsDeviceQuery

What it means

PrintQueue.GetIsXpsDevice wraps a failure from ThunkIsMetroDriverEnabled (Win32 driver/DEVMODE query) into a PrintSystemException tagged 'PrintSystemException.PrintQueue.XpsDeviceQuery'. This check determines whether the queue's driver is XPS-based; the HResult carries the native error.

Solutions

Reinstall/repair the printer driver on the host and confirm DriverName resolves in PrintServer.GetPrintQueues().
Call queue.Refresh() before querying IsXpsDevice so the queue handle is initialized.
Verify the print server's driver architecture matches the client process.
Catch the exception and treat the queue as non-XPS if your workflow can fall back to GDI printing.

Example fix

// before
bool isXps = queue.IsXpsDevice;
// after
bool isXps;
try { isXps = queue.IsXpsDevice; }
catch (PrintSystemException) { isXps = false; } // fall back to non-XPS/GDI path

Defensive patterns

Strategy: fallback

Validate before calling

bool driverOk = !string.IsNullOrEmpty(queue.DriverName);
if (!driverOk) throw new InvalidOperationException("Queue has no usable driver; IsXpsDevice query would fail");

Try / catch

bool isXps;
try { isXps = queue.IsXpsDevice; }
catch (PrintSystemException) { isXps = false; } // degrade to non-XPS path

Prevention

Call Refresh() to initialize the queue before querying driver-derived properties.
Repair/reinstall broken driver packages on the print server.
Match client process architecture to the server's driver architecture.
Design printing code to tolerate unknown XPS capability (GDI fallback).

When it happens

Trigger: Accessing queue.IsXpsDevice (or APIs that query it like GetPrintCapabilities on a partially initialized queue) when the driver configuration query fails — driver missing/corrupt, DEVMODE unreadable, or the queue handle could not be opened.

Common situations: Legacy v3 driver uninstalled or upgraded concurrently; printer name resolved but driver package broken; remote queue on a server with different driver architecture (x64 vs ARM64).

Related errors

AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14). Data as JSON: /api/errors/3ca8d02ecc4ae46e. Report an issue: GitHub.

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/System.Printing/CPP/src/PrintQueue.cpp:2913

    void
    )
{
    Boolean printerIsXpsDevice = false;

    try
    {
        if (isBrowsable)
        {
            ActivateBrowsableQueue();
            isBrowsable = false;
        }

        printerIsXpsDevice = printerThunkHandler->ThunkIsMetroDriverEnabled();

    }
    catch (InternalPrintSystemException^ internalException)
    {
        throw CreatePrintQueueException(internalException->HResult,
                                        "PrintSystemException.PrintQueue.XpsDeviceQuery");
    }
    return printerIsXpsDevice;
}

Boolean
PrintQueue::IsXpsDevice::
get(
    void
    )
{
    VerifyAccess();

    if (!PropertiesCollection->GetProperty("IsXpsEnabled")->IsInitialized)
    {
        isXpsDevice = this->GetIsXpsDevice();
        PropertiesCollection->GetProperty("IsXpsEnabled")->IsInternallyInitialized = true;
        PropertiesCollection->GetProperty("IsXpsEnabled")->Value = isXpsDevice;

View on GitHub (pinned to 81131a70a4)