The case of the vanishing print jobs

First published on TECHNET on Jul 08, 2011

A while back, I worked on an interesting issue involving RDS EasyPrint. The issue was that the printers from the client were getting redirected in the RDS session using easy print driver. However no print job could be printed to these redirected printers. Interestingly, no events were reported in the event logs, the print job just appeared in the redirected print queue for a few second, and then vanished. We paused the print queue of the printer on the client, but no print job came through to the print queue.

With no events or errors to go with, I decided to collect Process Monitor logs on the server and the client, and try and see if we can track down where the print jobs were going. With a basic knowledge of how the print job flows from an RDS session to the client printer, I was hoping to track this down. Basically we will see the application in conjunction with the spooler process spools the print job. As EasyPrint is XPS based, the spooler process (spoolsv.exe) uses the XPS driver (PrintFilterPipelinePrxy.dll loaded inside spoolsv.exe and printfilterpipelinesvc.exe) to generate XPS job, which the spooler will then send to the client using the virtual channel of the client printer. On the client side, the job is received by the RDC client as a .tmp file in the user’s temp folder, and we have the Terminal Server Print Wrapper (TsWpfWrp.exe), which converts this to the EMF format along with the spooler and spools the job to the destined client print queue.

Using this knowledge, I started looking at the Process Monitor logs, first the server. We see the job getting spooled as below:

After this, we see spoolsv.exe on the server writing the print job to \Device\Rdpdr\tsclient\PRN2, which is the virtual channel for the client printer.

So it seems like the job does leave the server for the client. Now, looking at the Process Monitor log collected from the client, I first went to the process tree view, and do see the tswpfwrp.exe process, as a child process of Mstsc.exe.

Looking at the command line for the tswpfwrp.exe process, it looks like as below:

"C:\windows\system32\tswpfwrp.exe" "\\MachineName\printername" "C:\DOCUME~\username\LOCALS~1\Temp\XPS29C.tmp"

So it seems like we are failing to convert the XPS job we got from the server and send it to the print queue at the client. To ensure that we are headed in the right direction, I created a test XPS print job on my workstation and at command prompt ran the following command:

TsWrpWpf.exe testprinter <location of xps>\test.xps

After doing this, the print job did appear in the paused print queue. Using the same XPS file we tried the same command on the affected client machine. No print job appeared in the queue.

So, it’s the tswpfwrp failing to do the XPS to EMF conversion. A quick comparison of Process Monitor logs collected while running the TsWrpWpf command as above, we see that the process is unable to locate the binary printvpt.dll and this .dll is a part of XPS.

A quick Bing search on ‘XPS’ and ‘printvpt.dll’ led me to Microsoft Knowledge Base article 954550, which includes a hotfix that turned out to alleviate this issue:

http://support.microsoft.com/kb/954550 .

Anshuman Ghosh