PXC::IPXCControlEx::GetPrinterW() generating exception error

[nick.tucker]

Hi

I have an application which intermittently generates unhandled exception errors when run on some workstations.

The section of code used to create the PDF-XChange 4 printer instance is based on the given examples and looks like this:

{
CLSID clsid;

if (SUCCEEDED(CLSIDFromProgID(L"PXCComLib.CPXCControlEx",&clsid)))
m_pFactory = PXC::IPXCControlExPtr(__uuidof(PXC::CPXCControlEx));

if (m_pFactory != NULL)
{
if (m_pPrinter == NULL)
{
m_pPrinter = m_pFactory->Printer[L"", L"PDF-XChange 4.0", L"OUR_REG_KEY,L"OUR_DEV_CODE"];

if (m_pPrinter != NULL)
{
DispEventAdvise(m_pPrinter);

m_pPrinter->ResetDefaults();
m_pPrinter->Option[L"Save.SaveType"] = L"Save";
m_pPrinter->Option[L"Save.ShowSaveDialog"] = L"No";
m_pPrinter->Option[L"Save.File"] = m_pdf_path.GetString();
m_pPrinter->Option[L"Save.WhenExists"] = L"Overwrite";
m_pPrinter->Option[L"Save.RunApp"] = FALSE;
m_pPrinter->Option[L"Overlay.Enabled"] = FALSE;
m_pPrinter->Option[L"Compression.Graphics"] = TRUE;
m_pPrinter->Option[L"Compression.Text"] = TRUE;
m_pPrinter->Option[L"Fonts.EmbedAll"] = FALSE;
m_pPrinter->Option[L"Saver.ShowProgress"] = FALSE;
m_pPrinter->ApplyOptions(0);
}
}
}

This is working well on the vast majority of deployed systems but on some workstations, an exception is intermittently generated, some workstations fail much more consistently than others.

I have attached a minidump so you can see where the failure is occurring - it seems to be when processing source line:

m_pPrinter = m_pFactory->Printer[L"", L"PDF-XChange 4.0", L"OUR_REG_KEY,L"OUR_DEV_CODE"];

in function PXC::IPXCControlEx::GetPrinterW().

We are developing under Visual Studio 2010 but have the same problem using Visual Studio 2008 and Visual Studio 2005.

Please help!

Thanks

[Tracker Supp-Stefan]

Hello Nick Tucker,

While I get one of our devs to check this could you please confirm the build number that you are using.
You can check the dll files and in the status bar the and in the properties window for those files the build should be visible.
If it is not 4.0.195 - then please try with the latest one and see if the problem still persists.

Best,
Stefan

[nick.tucker]

Hi Stefan

Sorry, I should have added to my original post that the build number in use is 4.0.195 - I have verified the components loaded when the error occurs are at that build.

Thanks for your swift response so far!

Nick

[nick.tucker]

Hi again

I have accidentally found another scenario with the above code today which produces similar results.

When running the code in Visual Studio, I had the code break after the creation of the printer factory object but before the creation of the printer object. I was called away from my desk for a short while (10 minutes), when I got back, tracing over the printer creation code produced a very similar, if not the same exception. In the code below in pxccom.tli, the _hr value returned by getPrinter() is 0x800706ba (The RPC server is unavailable).

inline _variant_t IPXCControlEx::GetPrinter ( _bstr_t pServerName, _bstr_t pPrinterName, _bstr_t pRegKey, _bstr_t pDevCode ) {
VARIANT _result;
VariantInit(&_result);
HRESULT _hr = get_Printer(pServerName, pPrinterName, pRegKey, pDevCode, &_result);
if (FAILED(_hr)) _com_issue_errorex(_hr, this, __uuidof(this));
return _variant_t(_result, false);
}

I have re-run this a number of times, and the delay needed between the creation of the factory object and the creation of the printer object to reliably provoke this exception is 2 minutes or more.

Hope that helps

Nick

[Tracker Supp-Stefan]

Hello Nick,

There is an auto unload timeout which is by default set to two minutes, and is most probably what is causing this problem.
The auto unload is there in the end user drivers, and is also recommended for Citrix environments - where there would be loads of users connecting to the same hardware, but in your case - you might want to set the /AutoUnload "component" to 00 - which is infinite, when installing the drivers on customer machines.

Best,
Stefan

[nick.tucker]

Hi Stefan

Thanks for your reply. OK, let's assume the two-minute timeout is a red herring here (unless the failing systems take over two minutes to process those two calls!).

Can your devs still take a look at the problem as originally reported.

Thanks

Nick

[Tracker Supp-Stefan]

Hi Nick,

Yes - the AutoUnload is unlikely the cause of the initial problem, and yes I have already passed the case to the guys and am expecting the answer really soon.

Best,
Stefan

[Paul - Tracker Supp]

Hi Nick,

the development team leader has attempted to reproduce this without success. He suggests that it could be the unload as Stefan mentioned but that until we can reproduce this we cannot say this is the case with any real certainty.

Can you tell us under what conditions you see this? Can you advise what steps we should take to reproduce this?

thanks

[nick.tucker]

This surely cannot be an unload problem since unload problems only occur if two minutes or more elapse between the creation of the factory object and the creation of the printer object. This scenario only happened on my test rig because I was running it under the Visual Studio debugger and had a debug breakpoint set after the creation of the factory object; I left my desk for a while before resuming execution hence a legitimate timeout had occurred. I hope those few lines of code given always take less than two minutes to run unattended!

I am unable to reproduce this problem on demand for you - it is affecting a few of my customers but the only input I am able to get from them is in the form of automated minidumps of the kind I have already sent you.

Are there other scenarios which might cause an unload problem that we haven't considered?

[Paul - Tracker Supp]

Hi Nick,

This surely cannot be an unload problem since unload problems only occur if two minutes or more elapse between the creation of the factory object and the creation of the printer object.

Actually the time out is 30 seconds from the time you create the factory object. If the printer is not created pdfsaver will close.

hth

[DISystemer]

Hi,

I have the same problem as Nick. The call to IPXCControlEx.Get_Printer return an EOleException with message "Unspecified error".

We use Delphi XE, and we also have the same problem when running tracker's DriverAPI example program. Code:

Code: Select all

procedure TForm1.InitSaverObj;
var
  prnt:OleVariant;
begin
  PDFPFactory:=CoCPXCControlEx.create;

  if PDFPFactory=nil then
  begin
    ShowMessage('PDF-XChange 4.0 SDK not installed or not properly registered. Application will quit.');
    Halt(0);
  end;
  prnt:=PDFPFactory.Printer['', 'PDF-XChange 4.0 Sample', '<reg-code>', '<dev-code>'];

  PDFPrinter:= IDispatch(prnt) as CPXCPrinter;

  FEventSink := TEventSink.Create(form1);
  InterfaceConnect(PDFPrinter,_IPXCPrinterEvents,FEventSink,FConnectionToken);

  PrinterName := PDFPrinter.Name;
  IsPXCPrinterDefault := false;
end;

The call to PDFPFactory.Printer[] produces an EOLEException error.
In this case there are no delay between the creation of the Factory objedct and the call to Get_Printer.
The PDF X-Change 4.0 Printer is installed.

Our environment:
PDF-XChange 4 Drivers API v. 4.0.195
Windows 7 Professional SP1 64-bits
Embarcadero Delphi XE Version 15.0.3953.35171

Any suggestions?

[Ivan - Tracker Software]

Do you know error code of the exception ?

[DISystemer]

Yes, the error code is -2147467259 (0x80004005).

[Ivan - Tracker Software]

I will prepare and send you debug version of pdfSaver4.exe (COM server for AX) and port monitor's DLL.
Using the Debug View utility, we will be able to find where and probably why an error occurred.

[DISystemer]

Still no debug version received...

[Tracker Supp-Stefan]

Hello DISystemer,

I will check with Ivan for the status of the debug build, and in the mean time can you please confirm that the e-mail listed for your forum account is the correct one?

Best,
Stefan

[DISystemer]

yes, the e-mail address is correct.

[Tracker Supp-Stefan]

Thanks DISystemer,

Will check with Ivan, and we will see to send you the custom build as soon as possible.

Best,
Stefan

[dwallen]

I had the same issue but was able to resolve on my own. It wasn't obvious why I had the problem. In my case I was creating the Factory at form load thinking that I'd do this once instead of each time I create a printer. So I had the following...

Private PDFPFactory As New PXCComLib.CPXCControlEx

Then upon the users choice to start capturing printed output I would later create a printer with the following....

PDFPrinter = PDFPFactory.Printer("", "eDoc", "", "")

All I had to do to produce the problem was wait 60 seconds after program launch and then try to create the printer. I'm not sure why but I have gotten two different errors as follows:

The RPC Server is unavailable. 0x800706BA (this is the one I usually get)
The object invoked has disconnected from its clients. 0x80010108 (i've seen this one at least once)

This all seems to be by design. After creating the Factory PDFSaver4.exe will run for 60 seconds and then terminate (I understand from the above that this is configurable). After it terminates, attempting to create a printer will fail. The solution was simple in my case, but figuring out the issue was time consumming. If creating a printer must happen within a certain time period after creating the factory is a requirement some documentation could have saved a little pain.

Other than this (and an OnError and OnDocEnd events issue posted in another thread) I've been very pleased with the product.

I hope this is helpful to others.

[John - Tracker Supp]

Many thanks for the input - very much appreciated and hope that helps others and you can set PDFSaver both to a configurable time out or indeed not to close at all ...

See the 'AutoUnload' method in the help for further info.

Cheers

[nick.tucker]

Hi

For anyone still out there, I have at long last worked around this problem by catching the exception and retrying thus:

for (;;)
{
CLSID clsid;

try
{
CLSID clsid;
if (SUCCEEDED(CLSIDFromProgID(L"PXCComLib.CPXCControlEx",&clsid)))
m_pFactory = PXC::IPXCControlExPtr(__uuidof(PXC::CPXCControlEx));
}
catch(_com_error &e)
{
continue;
}

if (m_pFactory != NULL)
{
if (m_pPrinter == NULL)
{
try
{
m_pPrinter = m_pFactory->Printer[L"", L"PDF-XChange 4.0", L"OUR_REG_KEY,L"OUR_DEV_CODE"];
}
catch(_com_error &e)
{
m_pPrinter.Release();
continue;
}

if (m_pPrinter != NULL)
{
DispEventAdvise(m_pPrinter);

m_pPrinter->ResetDefaults();
m_pPrinter->Option[L"Save.SaveType"] = L"Save";
m_pPrinter->Option[L"Save.ShowSaveDialog"] = L"No";
m_pPrinter->Option[L"Save.File"] = m_pdf_path.GetString();
m_pPrinter->Option[L"Save.WhenExists"] = L"Overwrite";
m_pPrinter->Option[L"Save.RunApp"] = FALSE;
m_pPrinter->Option[L"Overlay.Enabled"] = FALSE;
m_pPrinter->Option[L"Compression.Graphics"] = TRUE;
m_pPrinter->Option[L"Compression.Text"] = TRUE;
m_pPrinter->Option[L"Fonts.EmbedAll"] = FALSE;
m_pPrinter->Option[L"Saver.ShowProgress"] = FALSE;
m_pPrinter->ApplyOptions(0);
}
}
}

break;
}

My experiences in the field show that COM exceptions are generated when the factory object is created, as well as when printer objects are created.

This is with build 201 deployed.

Should I be doing this in a more appropriate manner?

Thanks

[Tracker Supp-Stefan]

Glad to hear that you finally managed to handle it Nick,

Hope it would be useful to someone else!

Cheers,
Stefan