V4 Printer Extension crashes with Japanese as System Encoding. RRS feed

  • Question

  • Hello everyone,

      I'm experiencing a crash related to storing UTF-8 text (in this case, Japanese) in the User Property bag of a V4 Printer Driver while the system is using the Japanese System Encoding (you can know this is the case when the backslash character in Command Prompt appears as a Yen currency symbol). The values in the User property bags are used as values for the ParameterInits for the Print Ticket. The Print Tickets appear fine (e.g: <psf:Value xsi:type="xsd:string">123</psf:Value>). The 1 2 3 string here is composed of 3 three full-width alphanumeric characters (Japanese encodings have these character sets).

      A freshly installed driver doesn't cause the crash because there is nothing in the user property bags yet. But when the user types something Japanese, saves it, and reloads the Printer Extension (through Devices and Printers), it will not show up and instead display the standard UI. I have added a try-catch inside the OnDriverEvent event handler but I'm not getting any exceptions.  Even the MessageBox that appears so that I can attach the debugger doesn't appear at all. (This MessageBox call is the first one to be executed in the OnDriverEvent handler).

      Could this be a bug of the V4 Print Architecture?


    Monday, June 17, 2013 12:46 AM


All replies

  • Hi John,

    I'm assuming you're using the SetString/GetString methods to set the Japanese String object into the user property bag? We haven't seen a report of this particular behavior. Can you please open a case with WDK Support? They can debug the situation and see what's happening on the Windows side as well as possible issues in your code.



    Monday, June 17, 2013 6:16 PM
  • Hello Justin,

       Thanks for your reply.

       Yes I am using the SetString/GetString methods of the user property bag in our C# code (the functions accept and return the .NET string type which I believe supports Unicode encoding). 

       As a workaround for this, unicode strings are converted first to their ASCII-readable counterparts (Base64 or hex string) and then stored to the user property bag. Appropriate conversion takes place during reading as well. 


    Tuesday, June 18, 2013 1:57 AM
  • Hi Justin,

    I have noticed this issue also of trying to save Japanese strings to the DevMode map using fresh install of Windows 8. But after applying all the updates, this issue doesn't happen anymore.

    Unfortunately, now the behavior is different. I can see that the Japanese strings are stored and retrieved correctly in the DevMode map ( in the javascript constraint file - Devmode to PT and PT to Devmode). The PrintTicket is properly constructed in the javascript. But when it's time to pass it to the PrinterExtension, it crashes. The data ( PrintTicket ) seems to not reach the PrinterExtension.

    This issue does not happen in Windows 8.1. Also, this happens in a native Windows 8 Japanese 64 bit OS. Using a Windows 8 English version, the crash does not happen but the Japanese data is corrupted.

    Thursday, March 6, 2014 5:24 PM