Quick PDF Library 7.13 on 64-bit

Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic

   We have been running QuickPDFDLL 7.13 on a 32-bit Windows 2003 for over 4 years now.  We are preparing to move to Windows 2008 64-bit and I'm having issues with the DLL.	
I followed the steps of changing the platform target to x86 in the article on your site, but still no success.  The error I'm receiving is "Unable to read data from the transport connection". The event viewer is showing:

Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7a5f8
Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec49b8f
Exception code: 0xc0000374
Fault offset: 0x000ce6c3
Faulting process id: 0x10c4
Faulting application start time: 0x01ce50c4b5cb678d
Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
Faulting module path: C:\Windows\SysWOW64\ntdll.dll
Report Id: 07f2d845-bcb8-11e2-90e7-00155d2dd431

Any ideas?

Thanks!

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version Translate Topic
alorie Members Profile Find Members Posts Beginner Joined: 14 May 13 Location: Miami, FL Status: Offline Points: 8	Post Options Post Reply Quote alorie Report Post Thanks(0) Quote Reply Topic: Quick PDF Library 7.13 on 64-bit Posted: 14 May 13 at 6:26PM
	We have been running QuickPDFDLL 7.13 on a 32-bit Windows 2003 for over 4 years now. We are preparing to move to Windows 2008 64-bit and I'm having issues with the DLL. I followed the steps of changing the platform target to x86 in the article on your site, but still no success. The error I'm receiving is "Unable to read data from the transport connection". The event viewer is showing: Faulting application name: w3wp.exe, version: 7.5.7601.17514, time stamp: 0x4ce7a5f8 Faulting module name: ntdll.dll, version: 6.1.7601.17725, time stamp: 0x4ec49b8f Exception code: 0xc0000374 Fault offset: 0x000ce6c3 Faulting process id: 0x10c4 Faulting application start time: 0x01ce50c4b5cb678d Faulting application path: C:\Windows\SysWOW64\inetsrv\w3wp.exe Faulting module path: C:\Windows\SysWOW64\ntdll.dll Report Id: 07f2d845-bcb8-11e2-90e7-00155d2dd431 Any ideas? Thanks!

Ingo Members Profile Find Members Posts Moderator Group Joined: 29 Oct 05 Status: Offline Points: 3524	Post Options Post Reply Quote Ingo Report Post Thanks(0) Quote Reply Posted: 14 May 13 at 9:49PM
	Hi! Are other old processes running errorfree on the new server? Did you insert the 32-bit-w3wp.exe and -ntdll without reinstall into the new SysWOW64? Perhaps this issue has to do with the new access rights of Win2008? Try Google with your error message ... there's a lot. Cheers and welcome here, Ingo

alorie Members Profile Find Members Posts Beginner Joined: 14 May 13 Location: Miami, FL Status: Offline Points: 8	Post Options Post Reply Quote alorie Report Post Thanks(0) Quote Reply Posted: 15 May 13 at 7:31PM
	We use the QuickPdfLibrary dll within our application. The aplication is working fine except for the printing. Not sure what you;re taling about when you say "Did you insert the 32-bit-w3wp.exe and -ntdll without reinstall into the new SysWOW64?" I checked the SySWoW64 folder and I can see the 32-bit-w3wp.exe and -ntdll. Not sure what you mean by "without reinstall"."

Ingo Members Profile Find Members Posts Moderator Group Joined: 29 Oct 05 Status: Offline Points: 3524	Post Options Post Reply Quote Ingo Report Post Thanks(0) Quote Reply Posted: 15 May 13 at 10:29PM
	I mean new win setup or only putting the old dlls and exes into the new target paths without real new install. BTW: There's a new 64-bit-version available, too ;-)

alorie Members Profile Find Members Posts Beginner Joined: 14 May 13 Location: Miami, FL Status: Offline Points: 8	Post Options Post Reply Quote alorie Report Post Thanks(0) Quote Reply Posted: 17 May 13 at 9:31PM
	Thanks for your help. I was not able to print using the older version of QuickPDF so now I'm trying with a newer version (9.13). The issue I'm having at the moment is that the NewCustomPrinter method is returning blank/null after calling it instead of getting the long number that identifies the printer. Seen this before.?

Ingo Members Profile Find Members Posts Moderator Group Joined: 29 Oct 05 Status: Offline Points: 3524	Post Options Post Reply Quote Ingo Report Post Thanks(0) Quote Reply Posted: 17 May 13 at 10:26PM
	Please read here what the function should return: http://www.quickpdflibrary.com/help/quickpdf/NewCustomPrinter.php And read there what you have to do before. If there's no returning "name" you should use LastErrorCode to see what's going on. Cheers, Ingo

alorie Members Profile Find Members Posts Beginner Joined: 14 May 13 Location: Miami, FL Status: Offline Points: 8	Post Options Post Reply Quote alorie Report Post Thanks(0) Quote Reply Posted: 20 May 13 at 6:36PM
	Using LastErroCode the return value = 0.

AndrewC Members Profile Find Members Posts Moderator Group Joined: 08 Dec 10 Location: Geelong, Aust Status: Offline Points: 841	Post Options Post Reply Quote AndrewC Report Post Thanks(0) Quote Reply Posted: 21 May 13 at 2:20AM
	What is the name of the printer you are trying to connect to ? What is the exact string you are passing to QP.NewCustomPrinter ? Does QP.GetDefaultPrinterName return a valid result ? Does QP.GetLatestPrinterNames return a correct result ? Is it a virtual printer or a printer that is installed locally ? Andrew.

alorie Members Profile Find Members Posts Beginner Joined: 14 May 13 Location: Miami, FL Status: Offline Points: 8	Post Options Post Reply Quote alorie Report Post Thanks(0) Quote Reply Posted: 21 May 13 at 2:52PM
	printer name is: \\s096v018\DOUG-Room 333-32-HP Laserjet P4014 PCL 6 64-bit we do not use QP.GetDefaultPrinterName. We get the printer path from a database and pass it to Qp.NewCustomPrinter. This is working for us in our production environment using version 7.13 This printer is on a separate print server. Thanks, Albert

alorie Members Profile Find Members Posts Beginner Joined: 14 May 13 Location: Miami, FL Status: Offline Points: 8	Post Options Post Reply Quote alorie Report Post Thanks(0) Quote Reply Posted: 21 May 13 at 8:01PM
	I tested using QP.GetDefaultPrinterName and it worked. I compared the strings and found this: \\s096v018\DOUG-Room 333-32-HP Laserjet P4014 PCL 6 64-bit vs. \\s096v018\DOUG/Room 333-32/HP Laserjet P4014 PCL 6 (64-bit) So there was a change from 7.13 to the newer version in what printer path we use?

alorie Members Profile Find Members Posts Beginner Joined: 14 May 13 Location: Miami, FL Status: Offline Points: 8	Post Options Post Reply Quote alorie Report Post Thanks(0) Quote Reply Posted: 22 May 13 at 6:18PM
	Update: While I was able to get printing to work I have found an issue that we do not have currently in our production environment using version QuickPDFLibrary v7.13. In our IIS app server we use a domain service account as the Application Pool identity. In order for printing to work I had to log in to the server as the service account and add the printers (Devices and Printers). Can someone explain what has changed that I have to do this now? With the previous PDF library we do not have to do this! Thanks!

Wheeley Members Profile Find Members Posts Senior Member Joined: 30 Oct 05 Location: United States Status: Offline Points: 146	Post Options Post Reply Quote Wheeley Report Post Thanks(0) Quote Reply Posted: 22 May 13 at 7:19PM
	Actually, this is a Windows issue and not a QuickPDF issue. Printers are user specific in Windows meaning each user account for a computer has its own printers list. So since you setup IIS app to run under a specific user, the application only sees the list of printers for that user. The same issue happens for Window Services also. If a service runs under a specific user then only the installed printers for that user are visible. Wheeley

alorie Members Profile Find Members Posts Beginner Joined: 14 May 13 Location: Miami, FL Status: Offline Points: 8	Post Options Post Reply Quote alorie Report Post Thanks(0) Quote Reply Posted: 22 May 13 at 7:27PM
	I understand that, but this is not an issue in version 7.13 and now in the new version it is? I would prefer that we not have to do this. Thanks, Albert Edited by alorie - 22 May 13 at 8:00PM

AndrewC Members Profile Find Members Posts Moderator Group Joined: 08 Dec 10 Location: Geelong, Aust Status: Offline Points: 841	Post Options Post Reply Quote AndrewC Report Post Thanks(0) Quote Reply Posted: 23 May 13 at 2:42AM
	This is a new issue for Windows Server 2008. It is 2008 that has changed and not QPL 7.13. GetDefaultPrinterName has not changed the printer name. It is more likely that Server 2008 is reporting the printer name differently now. Here are some ideas that might work http://stackoverflow.com/questions/16040148/add-printer-to-local-computer-using-managementclass http://stackoverflow.com/questions/13966188/how-to-use-win32-classes-like-win32-printer

redtaped Members Profile Find Members Posts Beginner Joined: 13 Nov 13 Location: Lake Mary Status: Offline Points: 3	Post Options Post Reply Quote redtaped Report Post Thanks(0) Quote Reply Posted: 13 Nov 13 at 3:11PM
	Hi, I'm trying to do something similar. We have a database of UNC paths to printers. These are not necessarily mapped to the local users computer. When I try to print to an unmapped printer, it doesn't work. NewCustomPrinter returns blank. May I ask how you were able to overcome this? Thank you, Jamieson