Paper size & "Unable to start the print job. ... security context."

[patrick_simons2]

Hi,

I'm using CR for VS SP34, the local printer is a "HP Color Laserjet Pro M452nw" (with the latest driver).

When printing with POC (_crystalMainReport.ReportClientDocument.PrintOutputController.PrintReport(_pocReportOptions) ) to the HP Printer,
I get "Unable to start the print job. It may not be possible in the current security context."

When printing with P2P (_crystalMainReport.PrintToPrinter(copies, collateCopies, 0, 0) ) to the HP Printer,
I get "The data area passed to a system call is too small."

After some research I found out that _not_ explicitly setting the paper size in _pocReportOptions causes the problem.

The default paper size in the printer driver is A4.
The default paper size in the generic report is A4 (with both "no printer" and "Dissociate Formatting Page Size and Printer Paper Size" checked).

If I don't set the paper size, the value of _pocReportOptions.PaperSize remains on CrystalDecisions.ReportAppServer.ReportDefModel.CrPaperSizeEnum.crPaperSizeDefault.Then on the PrintReport, the error is raised.

As Don explained some time ago, there is some printer info stored inside the report file and as "No Printer" is checked, there are some matching tests internally in CR. Maybe here comes a bug?

I can reproduce this behavior with Don's test solution (RAS2010_Printing).

If I change the no printer flag in the report (uncheck + check - so nothing changed), save the report, then the error has gone away - strange... In any case, it would be appropriate to get a clearer message text...

If I use another printer, it works fine.

Thanks for any explanation.

Patrick

[DonWilliams · Accepted solution]

Hi Patrick,

Because you are not using the Clone option it has the potential to cause a random error depending on the printer used.

As noted, CR requires a default printer defined in the RPT file, it uses part of usp10.dll to generate part of the formatting along with part of the Default printer info from DEVMODE structure.

The Set Printer routines are there for a reason, you need to use that routine if the report needs a real printer.

The reason I had 3 Printer routines, Set Printer, P2P and POC was for testing in various scenarios ONLY, the work flow depending on your Reports doesn't change. Set Printer, if No Printer is used, is why I specifically check for No Printer and the other 2 if the Report Design printer does/Does Not exist but you want to change it to some other printer at runtime.

So if No Printer is saved in the Report then you need to use the Clone API to set the printer info if unique printers are required than from the original design Default printer properties. Or in your case something in the Default properties saved in the RPT file is different and causing an error to generate when using the POC API's without the Clone API being used.

Doesn't matter if I can reproduce the exact error. Also explains why you didn't get the Report not found if you used the Set Printer button.

You quoting the help file you missed one important part that is pertinent to this discussion:

"For example, some printer drivers contain memory leaks or file handle leaks. If a report is configured for a printer driver that has one of those issues, the performance of the report is adversely affected."

So this is likely the cause, something in that HP printer driver is causing those specific errors to be generated.

And typical DLL error handling, that error is being passed to the you by Your EXE from the OS, it's not a CR error message so nothing for DEV to fix.

A quick search on the Data error error returns a Microsoft Error not related in this case to printing but the error message is exact so just to show you it's not a CR error. The other one is likely cause by using using the Framework to print.

P2P jumps into crpe32.dll which uses the DEVMODE structure, POC does the same eventually after it goes through a few Framework dll's:

https://support.microsoft.com/en-gb/topic/kb4073393-fix-the-data-area-passed-to-a-system-call-is-too...

FIX: "The data area passed to a system call is too smal...

This issue occurs because of miscommunications between two filter drivers, specifically WCNFS (the Desktop Bridge) and the RsFxXXXX.sys driver (SQL Server ...

https://support.microsoft.com/en-gb/topic/-the-data-area-passed-to-a-system-call-is-too-small-error-...

"The data area passed to a system call is too small&quo...

This problem may occur when the full path of the driver file is longer than SMS 2003 can handle. Workaround. To work around this problem, use a shorter file ...

As for the work flow for your ERP software, as I noted the dummy reports do not need anything except the printer defined in the RPT file.

So what you could do is define a few typical printers, set the dummy report by name, so use a basic generic HP printer, don't use one of Microsoft's default printers, they have limitations also.

Another option is you could name the reports with the Printer name, check the Customers Default printers used and then set the Printer to their printer and load that dummy report.

My question to you is did you test using Set Printer to that HP printer and calling the routine to see if it generates any errors?

I also suggest you let HP know there's an issue with that print driver because Microsoft is reporting an error when it's used in a CR app.

There are work arounds, R&D won't do anything about the error since it's being reported by Microsoft.

Hope that helps.

Don

FYI - this isn't the first time HP printer drivers have/had issues...