NTDDL.DLL A/V when invoke within COM object

rbuser

We are running into an issue with v12 (reproduced with v12.04 and 12.05).

We previously were using v10.02 with Delphi 2007. We have a COM DLL which
includes the ReportBuilder components to generate PDF reports for a
website. This work correctly under this configuration.

With the v12.x version using Delphi XE we are receiving the following
error message:

2012-01-25 04:26:01.827 Main ERROR: Method
GenerateReport: Access violation at address 7C835663 in module
'ntdll.dll'. Read of address FFFFFFFF

This occurs when we call the .Print method. The BeforePrint event is
fired (which we have a handler for) which successfully finishes, and then
somewhere else the above exception occurs.

Oddly enough, if we consume the COM DLL with a Win32 Delphi app on the
same machine it runs correctly. It only seems to crash when invoked from
IIS (C# .NET website). This is occurring on a machine running Windows
2003 Server.

What suggestions do you have to aid in troubleshooting this issue? Are
there any logging mechanisms we can make use of?

Is this anything that you have seen with v12?




--- posted by geoForum on http://www.newswhat.com

nicocizik

Hi Britain,

This is not a known issue with RB 12. Do you see this behavior with
every report you try to export to PDF (even a minimal blank report)? If
you try to export to a different file type such as RTF, XLS, or Text, do
you still get the same error?

rbuser

I will try dtTextFile



--- posted by geoForum on http://www.newswhat.com

rbuser

?Same result.



--- posted by geoForum on http://www.newswhat.com

nicocizik

Do you see this behavior with every report you try to export (even a
minimal blank report)? Is there a certain component type on the report
that causes this issue?

rbuser

?I added logging within the report builder code and this is what I found
so far:

When it runs correctly, the TppPublisher.TakeDeviceAction method is called
many times (about 19). This is after the FPublisher.StartJob portion
which has one extra call to this method.

When it does not run correctly, this method only seems to run 3 times.

I will add more logging tomorrow morning.

In the mean time, any thoughts?



--- posted by geoForum on http://www.newswhat.com

nicocizik

Britain,

You have not answered my questions from my previous post .

Generally when an error is encountered when running ReportBuilder
non-locally (on a server), the problem is caused by insufficient access
privileges to items such as printer drivers or the hard drive.

Logging where the error is occurring in RB could be helpful if I knew
the exact type of report you were printing. This is why I would like
you to try a minimal (empty) report.

rbuser

We have used ProcMon (SysInternals) and don't see any obvious permission
issues.

I have created 9 versions of the COM DLL with progressively more of the
report content pulled out. I will let you know how these work.

The ReportBuilder report is in a COM DLL, that is being invoked from an
ASP.NET C# website. On some servers this works fine, on others it crashes.



--- posted by geoForum on http://www.newswhat.com

rbuser

Progress!

The Print Spooler service on the server was disabled. Enabling/starting
this service allowed the reports to be generated successfully.

This service has always been disabled on the servers (for PCI reasons).
It sounds like perhaps a change was made between v10 and v12 that places a
dependency on this service?



--- posted by geoForum on http://www.newswhat.com

nardmoseley

I cannot think of anything that has changed that would affect this. The RB
Printer related classes have been internally refactored and enhanced, but
are still using the same Windows API functions. It's up to Windows and the
printer driver how those functions are implemented, RB does not talk to the
print spooler.

Also keep in mind, you moved from D2007 to Delphi XE, so you are now using
Unicode VCL, which means all of the Windows API function calls are Unicode
so that could in theory be implemented by Windows or the printer driver in a
different manner. And perhaps you have changed Windows versions or applied
updates that changed something.

-
Nard Moseley
Digital Metaphors
www.digital-metaphors.com

rbuser

Thanks for the reply. I think for now the server guys are ok with leaving
that service on, so I would say problem solved.





--- posted by geoForum on http://www.newswhat.com