Access violation in ucrtbase.dll

jajaja

Hello,
I have a reports wich almost everytime causes my application to crash. Sometimes the message "Access violation at adress 76ADFC8E in module 'ucrtbase.dll'.
It only happens if I print the report from my application buils in Delphi 10.4.
It happens at my customer's PC's, and also on my own.

Another application, compiled in Delphi2007, uses the exact same report without any problem.

I spent days trying to isolate the cause of this bug, but without any result.

Any hint in the right direction is very much appreciated.

kind regards,

Dirk Janssens

nicocizik

Hi Dirk,

We have not heard of this issue before.

Try commenting out all event/RAP code to see if that is causing the problem. Also try is disconnecting the report from data.

Another suggestion is to create a simple application that is capable of running one of the affected reports and testing with that. This will verify that it is the report itself that is causing the problem.

If you are still able to get the issue with a simple app, please send it to us for testing. Be sure you are using the latest version of ReportBuilder and have all available patches/updates installed for Delphi 10.4.

jajaja

Hi Nico,

It is very hard to reproduce. It seems to be a combination of things.
The most 'promising' hint is : as soon as I Open Edge, while the report is beïng generated, big cahnce I get the error ( "Access violoation in ucrtbase.dll" ).

To give you an idea how I test:
I stripped the report to almost 'empty' , and made a loop that automaticly generates the report. At one time, it took over 14.000 times before the error occured. The second run, it came after 30 ...
That made me wonder if there was maybe an other process that caused the error. At one ttime, the error occured if I opened a specific website in Edge. It happend *every* time. BUT, the next day, the same test raised no error (!).

To be complete: : It does appear with simple reports, but with the original (2 subreports, 3 different datapiplines, 2 pages, so not really complex ) it happens a lot sooner.

I hope someone can make sence out of this ...

regards,

Dirk.

jajaja

After some more testing, I noticed that a difference between the report that crash and the others, is that there is a lot of binary data in the PrinterSetup.DevMode :
PrinterSetup.DevMode = {
180D00005C5C444330315C42524F544845525F48414E4E454B45000000000000
00000000010406029C007C0C0F930100010009009A0B34086400010007005802
01000200580201000000413400746F6D00000000000000000000000000000000
....

As soon as I delete this from the layout, the problem seems to be solved.
Only very few of my reports have this property.
What kind of data is stored in there, and is it likely/possible that it can cause a conflict with the ucrtbase.dll ?

kind regards,

Dirk Janssens

nardmoseley

Hi Dirk,

Use the Designer to edit the Report definition. Set Report.PrinterSetup SaveDeviceSettings False. Resave the report. The PrinterSetup.DevMode binary information will no longer be saved.

By default SaveDeviceSettings is False. Report.PrinterSetup.DeviceSettings can be used for cases in which a report needs to specify printer model specific configuration. For example to staple pages, or rotate paper, etc. This is done by pressing the ... button next to the DeviceSettings property and using the printer built-in properties dialog. Then information is saved as the DevMode binary structure. The DevMode binary info is specific to the printer model.