PDFXChange Viewer command line issue SOLVED

[RedWingFan]

Hi,

I have been using the PDFXchange View for a few years to do some automated printing of PDF's via a PHP script. It has been working flawlessly until the last week or so. Essentially, the PHP script creates a PDF, then shells PDFXCview.exe to print it:

Code: Select all

$WshShell = new COM("WScript.Shell");
$cmd = 'cmd /C "C:\\Program Files\\Tracker Software\\PDF Viewer\\PDFXCview.exe" /printto:showui=no '.$printer.' e:\\temppdfs\\'.$pdfname;
$exec = $WshShell->Run($cmd,0,true);

Normally, after this executes, I delete the temporary PDF, which is why I have the Run command waiting for the shell to finish executing before continuing on. However, for the last week or so, the PDFXCview.exe never closes after printing (it does actually print the PDF) and the shell never returns and the script hangs until PHP times out (actually, IIS times out the session).

My best guess is that something in the most recent batch or Windows Updates is interfering with the shell closing down properly. However, at this point in my testing, I haven't been able to pinpoint what. I have not yet tried to update PHP because of it being a production server, so I was hoping someone else might have experienced this recently and can offer some insight before I head down that road.

Thanks,

Eric

[Ivan - Tracker Software]

And you did not change the build of the Viewer? Can you please check if there is PDFXCview.exe process runned before you call call $WshShell->Run($cmd,0,true) ?

[RedWingFan]

There is the only the one call to the shell in the entire script. I updated the viewer to the latest version as my first step of troubleshooting, to no avail. I have been able to get PHP 5.6.10 (latest) installed and initial testing seems to still have the issue. I am going to try making similar calls with VBScript and/or PowerShell to see if they have issues, but not until tomorrow.

Eric

[RedWingFan]

So, further testing indicates that it isn't PHP. The issue is if the calling script/process runs as a background process. My PHP script runs in IIS and uses a specific worker process with a specific user account to run. I created a VBScript:

Code: Select all

Dim printer, pdfname, cmd

printer = "LP46"
pdfname = "mypdf.pdf"
cmd = "cmd /C ""C:\Program Files\Tracker Software\PDF Viewer\PDFXCview.exe"" /printto:showui=no " & printer & " e:\temppdfs\" & pdfname

Set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.Run cmd, 0, true

For my tests, I have created a test PDF that I can reuse indefinitely. I also did this with PHP (and wrote the same basic script as above in PHP, just to rule out the PDF creation process as a problem). If I run this script from the command line manually, it runs fine and closes. Same with the PHP script (i.e. php -f pdfprint.php). However, if I run this as a background task (e.g. via Task Scheduler using the same account that the IIS worker process uses) the PDFXCview.exe does not close out and the script hangs. With the PHP script, because it is being run by the IIS worker process, it runs as a background process as well.

For reference, I am running the latest version of PDF-XChange Viewer (v2.5.313.1) on Windows 2008R2 with latest updates (as of 1-JUL-2015). I have tested with PHP v5.5.8, 5.5.26, 5.6.0 & 5.6.10.

I'm not sure where to go from here. Because this process runs under IIS, I really don't have an option of running it as a "non-background" task. For the moment, I have changed the PHP script to not wait for the shell call to finish (i.e. $WshShell->Run($cmd,0,false); ) and disabled the automatic deletion of the PDF in the PHP script (deferring to a cleanup script that runs overnight). The issue is that this causes the worker process thread to stay open until it times out and recycles, which means that there is some resource utilization problems with that worker process & potentially multiple PDFXCview.exe processes hanging open until they timeout. This process doesn't get called a lot, so it shouldn't be critical, but this isn't a good long term solution.

Any thoughts?

Thanks,
Eric

[Ivan - Tracker Software]

Thanks for the very detailed explanation. We will investigate where the problem is and will come back soon with the result.

[RedWingFan]

No problem. Thanks for looking into it.

Eric

[Will - Tracker Supp]

[RedWingFan]

Did we find a fix for this? I see that there is a new version (2.5.314.0).

Eric

[Ivan - Tracker Software]

I could not reproduce the problem here. I did not use IIS, but add a Task Scheduler task to run your script and it works just fine for me.
I have suspicion that it might be related to the document you are printing. Or it is reproduced with any document?

[Mandino]

Any update on this? i'm having the same issue with a java service on a windows 8.1 machine, i'm using the last version (5.5 build 315)

[Mandino]

The java program runs the command "PDFXEdit.exe /importsettings" first with no problem and then "PDFXEdit.exe /print path_to_file", it prints the file just right but it doesn't return anything nor close the process

[Will - Tracker Supp]

Hi Mandino,

Can you please give the Editor a try? The Viewer has been discontinued, as it was replaced by the Editor some time ago and, as such, very few changes (likely none) are being made:
https://www.pdf-xchange.com/PDFXVE5.zip

Thanks,

[Mandino]

That's the one i'm using, version 5.5 build 315

[Will - Tracker Supp]

Hi Mandino,

Sorry, I'd missed that - will see if I can get an update for you today.

Cheers,

[Will - Tracker Supp]

Hi Mandino,

We've just noticed that your command string is as follows:

cmd = "cmd /C ""C:\Program Files\Tracker Software\PDF Viewer\PDFXCview.exe

This is the Viewer's executable. Are you still calling this exe in your string, or have you adapted to call the Editor's executable?

Thanks,

[Mandino]

I'm calling the new one, "C:\Program Files\Tracker Software\PDF Editor\PDFXEdit.exe"

[Will - Tracker Supp]

Hi Mandino,

Thanks for clarifying - Ivan is looking into this now.

[Vasyl-Tracker Dev Team]

Hi, Eric and Mandino.

We just reproduced your issue and will fix it in next build of our PDF-XChange Editor (approx. after 11 Jan).

Cheers.

[Mandino]

Thanks

[Tracker Supp-Stefan]