Application error pointing to acfpdf.dll when closing app

[eyost]

Hello,

I am in a terminal server environment using an application that uses an Amyuni driver to handle print to pdf. When I close the program I receive an application error that points to the following Amyuni .dll files:

acfpdfu.dll
acfpdf.dll
acfpdfui.dll
ACPgProc.dll
CDIntfNet.dll

The problem is the server is having memory resource issues after receiving the errors and eventually the Print to PDF function will not work until a reboot of the Terminal Server is performed.

The Amyuni driver that is being used is 2.10. Any ideas of what may be something to look at to resolve this? This occurs with all users including the Terminal Server Administrator.

Thanks for any help,

Ed

[Joan]

Hello,

Please give us more information on how you are using the driver, how you are printing to it and where are these dlls stored.

Thanks

[eyost]

Joan,

Sorry for the delay in replying to your inquiry. Here is the information that you requested.

Please give us more information on how you are using the driver, how you are printing to it and where are these dlls stored.

>>
We're using this driver to allow for "print to PDF" functionality in a Windows application (C++/MFC).

Upon checking, the .dll files are stored in the same directory as our application.

To use the functionality, we have a C++ class which wraps the functionality and is responsible for an explicit load of the cdintf.dll (via LoadLibrary call).

Upon installation we install both the Amyuni printer and a uniquely named printer that uses the Amyuni printer for print to pdf functionality. Our code is set to call upon the uniquely named printer to send the job to.

Let me know if you need any additional information.

Thanks,

Ed

[Joan]

Hello,

Are you installing your application and the DLLs of the PDF Converter on the server?
Are you installing the Printer on the server?

Do you remove the PDF Printer when closing your application or it is still there?

Do you call PDFDriverInit in your application?

Did you try to use version 2.50 to see if you will get the same issue?

What is the error you are getting?

I beleive this is an installation issue but it is hard to debug it in the forum this is why i am asking you a lot of questions.

[eyost]

Joan,

Sorry for the delay in replying, I had to attain the information from our developer.

Here are the replies to your inquiry.

Are you installing your application and the DLLs of the PDF Converter on the server?
Yes
Are you installing the Printer on the server?
Yes

Do you remove the PDF Printer when closing your application or it is still there?
No

Do you call PDFDriverInit in your application?
From InitInstance() in our main CWinApp-derived class (we're using MFC, dynamically linked to our app), there are 2 calls to initialize the PDF DLL:
m_PDFConverter.PDFConverterLoadDLL();
m_PDFConverter.PDFConverterInit();
That m_PDFConverter object is derived from a class that we use to encapsulate the functionality in the Amyuni DLL. The constructor of that class sets some members to NULL. The PDFConverterLoadDLL() function basically does the following:
LoadLibrary(_T("cdintf.dll"));
... plus some other minutiae, like error-handling.
The PDFConverterInit() does the following:
DriverInit = (DriverInitProc) GetProcAddress(m_hLib, _T("DriverInit"));
DriverEnd = (DriverEndProc) GetProcAddress(m_hLib,_T("DriverEnd"));
SetDefaultFileName = (SetDefaultFileNameProc) GetProcAddress(m_hLib,_T("SetDefaultFileName"));
SetDefaultPrinter = (SetDefaultPrinterProc) GetProcAddress(m_hLib,_T("SetDefaultPrinter"));
RestoreDefaultPrinter = (RestoreDefaultPrinterProc) GetProcAddress(m_hLib,_T("RestoreDefaultPrinter"));
SetFileNameOptions = (SetFileNameOptionsProc) GetProcAddress(m_hLib,_T("SetFileNameOptions"));
EnablePrinter = (EnablePrinterProc) GetProcAddress(m_hLib, _T("EnablePrinter"));
if ((DriverInit == NULL) || (DriverEnd ==NULL) || (SetDefaultFileName == NULL) || (SetFileNameOptions ==NULL) || (SetDefaultPrinter == NULL) || (RestoreDefaultPrinter == NULL) || (EnablePrinter == NULL))
return FALSE;
// Init the PDF Printer
if ((m_PDFPrinter = (*DriverInit)(SOFTPRO_PDF_PRINTER)) == NULL)
return FALSE;
return TRUE;

All in all, the answer is yes, we are calling the DriverInit function and verifying that a non-NULL value is returned.
We have many other customers that are running this configuration on a terminal server environment and it works fine on nearly all of our customers' machines.

Did you try to use version 2.50 to see if you will get the same issue?
We have not.

What is the error you are getting?
Illegal operation error pointing to our application.

Thanks for the help and let me know if you need any further information.