Win32Exception when printing to XPS document writer

Hi Tobias,

I'm trying to repro this but have not been able to.  We haven't changed that printing code in the WinForms SyntaxEditor in years either.  We effectively create a PrintDocument and then handle the various events like BeginPrint, PrintPage, and EndPrint.  Begin/EndPrint just create/destroy a special view for printing.  PrintPage just renders output to the e.Graphics that is passed.  I'm looking but am not sure what we could be doing to possibly cause this exception, other than if it's a lower level driver issue or something of that sort.  Can you repro it on other machines?

I tried to repoduce it with a Windows Vista virtual machine, but it worked there even after installing .Net 4.5. However other users in my organization have the same problem.

To be honest I don't really care about the XPS printing. I doubt a lot of our customers are actually using this. Most people use a PDF printer instead. My problem is that even when catching the exception, the form is never closed. I can continue to use my program, but I have to kill it via task manager.

Hi Tobias,

I'm not sure where we could catch that exception in addition to where you do.  The portion of our code that is in the stack is in the SyntaxEditor.Print method, where we do this line:

printSettings.PrintDocument.Print();

By you putting a try...catch around the SyntaxEditor.Print method call on your end, it's the same as if we'd add a try...catch inside our method.

I did some searching for the error message on the web and there's not much info on it.  One thread from years ago suggested that the problem might be that there aren't any physical printers installed on the problem computer.  Is that the case on yours?

I have several physical printers installed on my computer. All connected via the network. But as I said, I am pretty sure that it used to work.
Also the problem occures with the SDI sample too.

I just tested using the XPS printer with Microsoft Office 2010 and it failed too. The only difference is that there was no error and the app did not crash.
So I am guessing that my XPS printer must be corrupted. Since my co-workers have the same problem, I am assuming that the problem was introduced with an update. I will ask the IT deparpment if they have rolled out any specific updates or otherwise know the cause of the problem.

Hi Tobias,

Please let us know what you find out, thanks!

It seems the key to the problem is that the XPS document writer needs admin rights even if the user can write the target file.
For WPF applications on the other hand it is not required.

That's odd, we were able to print to XPS ok from the WinForms sample project, and didn't run the sample app with admin rights or anything.

Have you tried it with Windows 7? Unfortunately I can hardly find anything about that topic on the internet. But the issue appears throughout my company.

I am going to consider this issue as solved, since we cannot really do anything about it. If a customer has the same problem, at least we have a workaround.

Hi Tobias,

Yes I just tried on Windows 7 and had no problems.