Sometimes print jobs started by PrintQueueStream suffer an Exception in XpsRasterService.dll

New Contributor

The .NET class PrintQueueStream lets you copy xps content directly to a destination printer queue.
This method works OK on win10.

 

But exactly the same code running on win11 sometimes raises an Exception, always in the same place in code:

 

(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=????????????????

If the target printer driver reports xps in response to a GetDeviceCaps call GETTECHNOLOGY

 

GETTECHNOLOGY (20) : supported
Supported : http://schemas.microsoft.com/xps/2005/06

then there's no Exception.

 

But if GETTECHNOLOGY returns a non-XPS value then the Exception does occur.

 

This means that lots of printer drivers will likely fail until XpsRasterService is fixed. Using the HP Universal PostScript driver there's an error, because it reports itself as a PostScript technology. But the generic Microsoft PS and XL drivers don't have a problem because they report themselves as xps.

 

Here's a link to a zipped VS sln

1 Reply

@Kutana_Brian 

 

The optional update September 20, 2022—KB5017383 (OS Build 22000.1042) Preview (microsoft.com), which 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.