PrintQueue.GetPrintCapabilities throws when incorrect driver is configured for printer on print server - by Vadim Doroginin

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 690455 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 9/23/2011 7:11:29 AM
Access Restriction Public


PrintQueue.GetPrintCapabilities throws under several conditions.

System.Printing.PrintQueueException was unhandled
  Message=PrintTicket provider failed to retrieve PrintCapabilities. Win32 error: -2147467259
       at MS.Internal.Printing.Configuration.PTProvider.GetPrintCapabilities(MemoryStream printTicket)
       at System.Printing.PrintTicketManager.GetPrintCapabilitiesAsXml(PrintTicket printTicket)
       at System.Printing.PrintTicketManager.GetPrintCapabilities(PrintTicket printTicket)
       at System.Printing.PrintQueue.GetPrintCapabilities(PrintTicket printTicket)
       at ConsoleApplication1.Module1.Main()

Here is the condition: in printer properties under Advanced tab you have to select incorrect driver. For example: you have Samsung 4228FN and in printer properties you select Samsung ML-3550 driver.

I don't really know how bad it is to change driver to incorrect one, however, in our company there are about 40 printers, almost 80% of them is configured incorrectly (incorrect driver) and this configuration works for years now - every single program prints correctly in all modes possible. So, obviously, the problem is in .NET.

When you fire queue.GetPrintCapabilities(queue.UserPrintTicket) it throws mentioned exception.
When you create a new ticket, copy each field from UserPrintTicket to a new one - everything works great.
When you use UserPrintTicket.Clone - method GetPrintCapabilities with cloned ticket throws.

This behavior is tested on WinXP and Win7, both with latest updates. Dudes from DevExpress also reproduced the bug and helped to isolate the issue from calls to their libraries.

The background behind this problem is that XPS writer uses UserPrintTicket to print WPF visual and it fails in scenarios with incorrect driver. There is a workaround - you can assign newly created ticket to the queue.UserPrintTicket property.
Sign in to post a comment.
Posted by Microsoft on 9/28/2011 at 3:24 PM
Thank you for your feedback. We will not be able to get around to this area of the product in this release of WPF. Since you do have a workaround, you are not blocked and can continue to work.

WPF Team
Posted by MS-Moderator10 [Feedback Moderator] on 9/26/2011 at 11:26 PM
Thank you for submitting feedback on Visual Studio 2010 and .NET Framework. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by MS-Moderator01 on 9/23/2011 at 7:46 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(
Posted by Vadim Doroginin on 9/23/2011 at 7:22 AM
I've attached sample project which demonstrates the problem and the workaround.

        'queue.UserPrintTicket = ticket ' Uncomment this line to get Write method working

Remark: attached file didn't appear in file attachments, I believe there is some security check by Microsoft dudes which may take several days.