we are receiving an error that reads "There was an error found when printing the document 'Crystal Reports - document name'. Do you want to retry or cancel". One source is telling me it's a printer problem, another source is telling me there's nothing wrong with the printer. We've been printing to these same printers with the same report for many months & this error just started occurring. What could the cause be? It is likely it actually is a printer error vs. a report coding error? ANy help is appreciated, thanks!
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Printing Error
- Thread starter rcorners
- Start date
- Thread starter
- #3
Hi,
Given that, and since printing is handled client-side,
does the error happen regardless of what printer the user selects?
If so, it must be a problem originating when the report is generated so check the Event Viewer on the CE box for any error messages - also check any log files you may be creating..
![[profile]](/data/assets/smilies/profile.gif "[profile] [profile]")
Given that, and since printing is handled client-side,
does the error happen regardless of what printer the user selects?
If so, it must be a problem originating when the report is generated so check the Event Viewer on the CE box for any error messages - also check any log files you may be creating..
gregarican
IS-IT--Management
Are you still having this issue? Our site has a custom VB 6 app that interfaces with CR 8.5 runtime and has the same behavior. It affects a variety of Windows 2000 Professional workstations doing local printing to a variety of HP 4000, 4050, 4100, and 4200 printers. We have tried different LPT settings (EPP port option, ECP port option, job spooling on/off, bi-directional printing on/off, etc.) but to no avail.
Using network printing is more reliable however. It is frustrating to say the least. These errors are not happening 100% of the time, as they just pop up sporadically.
I've read a few things about the way that CR is being initialized/used/destroyed within VB code. That and perhaps new issues being apparent when using CR 8.5 or 9 versus CR 8. So far nothing resolved...
Using network printing is more reliable however. It is frustrating to say the least. These errors are not happening 100% of the time, as they just pop up sporadically.
I've read a few things about the way that CR is being initialized/used/destroyed within VB code. That and perhaps new issues being apparent when using CR 8.5 or 9 versus CR 8. So far nothing resolved...
gregarican
IS-IT--Management
Just bumping this up to see if anyone had run into anything new. Since our company is apparently hitting the same issue we've been banging our heads ever since.
gregarican
IS-IT--Management
Our environment has a server serving CE reports that are only used by one web client. But these are logically separate from the custom app. The same server happens to be running the SQL database, and the clients are all using VB6 with CR RDC 8.5 to get to that SQL data.
I have run the modules.exe that Crystal Decisions recommends and verified the craxdrtl.dll, crviewer.dll, and all other support files are running locally on the clients. Could the fact that the SQL box is running CE pose an issue using the client runtime dll's?
I have run the modules.exe that Crystal Decisions recommends and verified the craxdrtl.dll, crviewer.dll, and all other support files are running locally on the clients. Could the fact that the SQL box is running CE pose an issue using the client runtime dll's?
synapsevampire
Programmer
Try another printer, or install something like CUTEPDF which is a freebie PDF generating printer driver and see if it still fails.
If not, than there may be some problem with printing, such as permissions or settings, otherwise I'd try printing from another viewer, such as Active - X or Java.
-k
If not, than there may be some problem with printing, such as permissions or settings, otherwise I'd try printing from another viewer, such as Active - X or Java.
-k
gregarican
IS-IT--Management
I tried using a virtual printer port (which is a shareware util called Print Distributor). The virtual port sends the print job to the LPT port and prints the job to a PRN file. These failed job never even write out to the PRN file, much less hit the local printer. Here's what I ran into:
1. CR job fails to print directly to printer in the VB app.
2. Workstation exits the VB app and jobs still fail to print.
3. Workstation reboots and just a few print jobs later direct jobs fail to print to same printer.
4. I remote into the workstation and note that the CR progress window doesn't even launch when attempting to print these jobs.
5. I then go into the printer properties for the printer attempting the job and am able to successfully print a test page directly invoking the Windows printing subsystem.
6. I then go into a CR report that is generated in preview mode in the VB app (as opposed to being sent directly to the printer) and am able to successfully print to the same exact printer.
7. I exit the VB, relaunch it and am still unable to print jobs directly to the printer.
These steps tend to indicate that somewhere along the way the craxdrt.dll being referenced isn't "talking," if print previews (assuming they reference the crviewer.dll?) work and if Windows test pages work. I have patched all CR RDC files to 8.5.0.671, which I thought was the latest service pack.
Our company is at the point of totally rewriting the code to print these reports using native VB and bypass CR altogether. I have read product reviews in numerous places calling CR 8.5 a programmer's nightmare. Could this be true?
1. CR job fails to print directly to printer in the VB app.
2. Workstation exits the VB app and jobs still fail to print.
3. Workstation reboots and just a few print jobs later direct jobs fail to print to same printer.
4. I remote into the workstation and note that the CR progress window doesn't even launch when attempting to print these jobs.
5. I then go into the printer properties for the printer attempting the job and am able to successfully print a test page directly invoking the Windows printing subsystem.
6. I then go into a CR report that is generated in preview mode in the VB app (as opposed to being sent directly to the printer) and am able to successfully print to the same exact printer.
7. I exit the VB, relaunch it and am still unable to print jobs directly to the printer.
These steps tend to indicate that somewhere along the way the craxdrt.dll being referenced isn't "talking," if print previews (assuming they reference the crviewer.dll?) work and if Windows test pages work. I have patched all CR RDC files to 8.5.0.671, which I thought was the latest service pack.
Our company is at the point of totally rewriting the code to print these reports using native VB and bypass CR altogether. I have read product reviews in numerous places calling CR 8.5 a programmer's nightmare. Could this be true?
gregarican
IS-IT--Management
Here's a post-mortem regarding the printing issues I had. The issues weren't just confined to CR, as native VB printing resulted in the same sporadic issues. Hope this helps anyone is the same boat as I was 
As posted in an HP support forum...
Just wanted to let folks know about issues my company has seen with the HPDCMON.DLL process conflicting with the NTVDM/WOW32 process under Windows 2000.
A 16-bit legacy app that runs in our environment has to load under the NTVDM/WOW32 process in order to function on our Windows 2000 workstations. Occasionally this process loads right next to the memory address block where the Win32 Language Monitor for Direct Connect HP Printers process is loaded (aka HPDCMON.DLL).
This situation has caused sporadic printing issues where users receive the message 'There was an error printing the document ***document name*** to LPT1:. Do you want to retry or cancel?' The users have to totally reboot to recover local printing functionality. They don't run into these issues when the 16-bit app hasn't been initially loaded at all.
Since the NTVDM/WOW process stays loaded even after the 16-bit app has been exited there were sporadic printing issues over time no matter if the 16-bit app was actually visible or not. This made it a bit tough to narrow down.
The only way that we were able to work around the issue was to disable the Win32 Language Monitor for Direct Connect HP Printers module.
Details on these points can be found in two Microsoft KB articles -->
and
Hope this can help anyone else out there who is in the same situation as I was. It took about a month to figure out all of this from trial and error!
As posted in an HP support forum...Just wanted to let folks know about issues my company has seen with the HPDCMON.DLL process conflicting with the NTVDM/WOW32 process under Windows 2000.
A 16-bit legacy app that runs in our environment has to load under the NTVDM/WOW32 process in order to function on our Windows 2000 workstations. Occasionally this process loads right next to the memory address block where the Win32 Language Monitor for Direct Connect HP Printers process is loaded (aka HPDCMON.DLL).
This situation has caused sporadic printing issues where users receive the message 'There was an error printing the document ***document name*** to LPT1:. Do you want to retry or cancel?' The users have to totally reboot to recover local printing functionality. They don't run into these issues when the 16-bit app hasn't been initially loaded at all.
Since the NTVDM/WOW process stays loaded even after the 16-bit app has been exited there were sporadic printing issues over time no matter if the 16-bit app was actually visible or not. This made it a bit tough to narrow down.
The only way that we were able to work around the issue was to disable the Win32 Language Monitor for Direct Connect HP Printers module.
Details on these points can be found in two Microsoft KB articles -->
and
Hope this can help anyone else out there who is in the same situation as I was. It took about a month to figure out all of this from trial and error!
- Status
Similar threads
- Locked
- Question
- Locked
- Question
- Locked
- Question
- Locked
- Question