Windows Update 27 May causing Report Pro 2 error

[jonhn]

I struck a strange error (attached screenshot) printing a Report Pro 2 report on a couple of client machines today, all from different sites, Win 11 machines.

After several years of this report working fine I knew it must be something like an update, which I was able to prove as the major factor.

From Claude:
The underlying cause is almost certainly that KB5089573 changed something in GDI+ or the print subsystem that affects how old 32-bit print contexts are initialised — ReportPro 2 is ancient enough that it hits edge cases in legacy print API calls that modern software wouldn't touch.

The fix options in order of ease:
1. Uninstall the update on the failing machines — Settings → Windows Update → Update History → Uninstall Updates → find KB5089573 and remove it. Machine will need a restart. Quickest fix and lowest risk.

What I would like to know is if anyone can tell me what windows doesn't like about ReportPro - it is only causing an error on one of about 15 different reports people use, so it is not universal, but if I can fix it programmatically that would be great.

Is there a different report generator that people like I should be changing to (that is easy)? I am using the 2019 version for XSharp 2.39.0.4

Thanks - hope this helps anyone trying to trouble-shoot the same thing.

Jonathan

[Chris]

Hi John,

If it's indeed the new update that caused the problem, it might be affecting other software as well and MS will hopefully release a patch fixing this. To be certain that this is what caused it, maybe you can ask one of your customers to roll back this update and see if everything works fine again?

As for what is the underlying reason for the problem is too hard to tell, you'd need to debug the report on site, or in your dev machine if you do get the same problem with the same report.

Incidentally, we are working on a replacement for report pro, a new reporting engine based on GDI+ written from scratch in X# which should be compatible with both RP and VFP reports and by coincidence just today we have a first (not feature complete yet) beta build for internal testing! Maybe you can send me this report (together with needed dbf files) to see if our new engine handles it well? And also maybe pinpoint a potential cause for RP2 failing on it..

[John Roe]

[EDIT]

Sorry folks, we jumped the gun there, the issue is still present on the later x# and ReportPro builds mentioned before. Unfortunately the machine the initial test was done on hadn't actually installed the windows update.

Sorry if this has caused any confusion for anyone

Karl (John's colleague)

[EDIT]


Hi Folks

We're keeping a close eye on this one as users began reporting it yesterday.

Reversing the Windows Update does fix the immediate issue and will buy a little time. The word is that the Windows Update contained a replacement Times New Roman font, but we were seeing it with Arial and Calibri too. Presumably it could happen with more fonts in the future.

The good news is that builds in X# 2.24 with RP2 2.43.1 work absolutely fine with the latest Windows Update, but our earlier releases built using X# 2.18 with RP2 2.36 do manifest the issue.

Does anyone know if there is anything to help users with legacy VO code running RP2? Presumably capping support to previous Windows versions is the only answer?

Thanks

John

[jonhn]

Hi Chris,

It must be the Times New Roman or particular font thing as John said- Times is the difference between the affected report and the ones that are ok at my end.
And, yes, I already rolled back the windows update to prove the issue before posting here.

On your new reporting engine I am very interested to try it out!
A few weeks ago I asked Claude and ChatGPT to compare our quotations against a competitor's to give recommendations on which is superior value (pasting the PDF's in) as any customer will be doing soon.

It turns out that my ReportPro ones are almost impossible for an Ai to make any sense of and our competitors created with a more modern generator were easy to read. Not OCR, reading the underlying text. It might be my terrible design and layout but Claude said none of the fields with prices or descriptions could be matched up nicely in the RP generated version.

I'm very interested, if you are looking for customers for it, to give it a try

Cheers,
Jonathan

Hi John,

If it's indeed the new update that caused the problem, it might be affecting other software as well and MS will hopefully release a patch fixing this. To be certain that this is what caused it, maybe you can ask one of your customers to roll back this update and see if everything works fine again?

As for what is the underlying reason for the problem is too hard to tell, you'd need to debug the report on site, or in your dev machine if you do get the same problem with the same report.

Incidentally, we are working on a replacement for report pro, a new reporting engine based on GDI+ written from scratch in X# which should be compatible with both RP and VFP reports and by coincidence just today we have a first (not feature complete yet) beta build for internal testing! Maybe you can send me this report (together with needed dbf files) to see if our new engine handles it well? And also maybe pinpoint a potential cause for RP2 failing on it..

[Chris]

Hi Jonathan,

OK, so the culprit is indeed almost certainly the change in the Times New Roman font, hopefully more programs will be affected and MS will be forced to fix it before we need to do anything.

Edit: Oh, I see the same problem is already reported again, so we probably have to fix it before MS does any action. If you can send us a sample report reproducing the problem it would be helpful.

About the new reporting engine, it is based on GDI+ and windows forms (which means we can also use dozens other available 3rd party libraries for pdf export, print preview dialogs etc), so possibly the text will be easier to be understood by AI, too. It reads report pro .rpt files (also supports hand written reports) and we are trying to make it as compatible to it as possible. It will be also possible to read Visual Fox Pro reports, so we can offer a migration path for reports also for this dialect.

It's still early days though, it only supports the standard report features for now. When it gets more complete, we will open a beta phase for it.

[John Roe]

Hi Chris

This has turned out to be a much bigger issue and our support team are under pressure from customers demanding a resolution. With over 250 report layouts on a typical client's site, it's a proving to be a mammoth task.

We started by advising clients to roll back the Microsoft Patch only to find it back again after the weekend!

Fortunately we have found the following Google Substitute Fonts for the problem True Type ones :

Arimo > Arial
Carlito > Calibri
Tinos > Times New Roman

By loading these new font definitions onto each workstation, and then bulk updating them in the headers of all the clients RPT files, we have a solution of sorts. While the fonts themselves are exact, their positioning and spacing as rendered by Report Pro are not quite exact. To keep customers happy we are having to manually reposition some of them in the Report Pro Designer.

Hopefully this might help anyone else experiencing these issues, but it would be better to have a proper solution if one can be found.

Many thanks

John

[Chris]

Guys,

Just to be clear, the problem only happens when you export a report to pdf, is that correct? Or does it happen also when previewing/regular printing?

[John Roe]

Hi Chris

Yes - it's only when sending the report to PDF that we see the issue. Otherwise the reports all preview and print as expected.

In VO, the application just terminates while in X# the following RP2 error appears in a Dialog Box:

The following error was encountered while fetching the next logical
record. Insufficient memory to continue the execution of the program.

On clicking OK, the report preview terminates but the main X# application continues to run.

Rolling back the Wondows Update or substituting the problem fonts addresses the problem for now.

Many thanks for your help.

John

[jonhn]

Yes, only with PDF output, but so far for my few users uninstalling that update has so far worked.
The workaround if that fails would be to output as preview and then the user can creative PDF from there, manually. A little annoying for the user.

[jotikasupport]

We are getting this error in our VO / Report Pro 2 product. Is there any update on this? Is it possible to get a fix for it?