Sometimes print jobs started by PrintQueueStream suffer an Exception in XpsRasterService.dll
See original GitHub issueDescription
The .NET class PrintQueueStream
lets you copy xps content directly to a destination printer queue.
This method succeeds on win10.
But exactly the same code running on win11 sometimes raises an Exception, always with the same stack trace:
(2ec4.11d4): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
XpsRasterService!xpsrdr::GetGlyphRunBounds+0xd9:
00007ffa`8638eb49 488b1b mov rbx,qword ptr [rbx] ds:00000000`00000000=????????????????
It doesn’t fail for every xps file, only some. In the linked solution, the file NatWest Welcome.xps succeeds, but the Kappris for Excel.win11.xps fails.
Both xps files get a 100% score from the MS isxps tool.
Reproduction Steps
This snippet is from the VS2019 solution whose link is below:
PrintQueue defaultPrintQueue = LocalPrintServer.GetDefaultPrintQueue();
string nextFile; // path to xps file
using (PrintQueueStream pqs = new PrintQueueStream(defaultPrintQueue, nextFile, true))
{
using (FileStream fs = new FileStream(nextFile, FileMode.Open, FileAccess.Read))
{
fs.Position = 0;
fs.CopyTo(pqs);
}
}
There’s a zipped VS2019 solution here, with sample XPS files. solution
Expected behavior
Any XPS file that gets a 100% score from MS isxps should print correctly.
Actual behavior
Some xps content fails to print.
Regression?
This worked in Windows 10, although XpsRasterService.dll
isn’t one of the dlls that gets loaded when you print with PrintQueueStream
on win10.
Known Workarounds
MS publish other methods for copying xps content to a target printer queue, which involve enumerating the xps content and calling an XpsDocumentWriter, and callbacks to add PrintTicket info per page. This technique is much slower than PrintQueueStream.
We favour PrintQueueStream because it heeds the PrintTickets within the xps. Not all available methods for printing xps pay any attention to the PrintTickets.
Configuration
If you use a printer driver whose GETTECHNOLOGY DeviceCaps query returns XPS then there is no error. But if the query indicates that this is a Postscript driver or PCL, then the error does occur. This means that older drivers (like the HP Universal PostScript Printer driver) fail.
Other information
No response
Issue Analytics
- State:
- Created a year ago
- Reactions:3
- Comments:7 (1 by maintainers)
Top GitHub Comments
After applying the optional update there’s no longer an AV printing the XPS files on Win11 so we consider this issue fixed.
The optional update September 20, 2022—KB5017383 (OS Build 22000.1042) Preview (microsoft.com) mentions this issue as below:
Addresses a known issue that affects XML Paper Specification (XPS) viewers. This might stop you from opening XPS files in some non-English languages. These include some Japanese and Chinese character encodings. This issue affects XPS and Open XPS (OXPS) files.
This issue was causing issues when reading XPS files with some specific characters (it was especially seen with some Japanese chars), causing GetGlyphRunBoundsEx() to possibly throw an AV but could also lead to infinite loops. The root cause on Windows 11 was related to the move to STL 110 C++ Runtime Library, which was leading to a slightly different behavior to the one on Windows 10 which we had to correctly handle.