Forum Discussion
Technical Issue - SSRS Power BI PDF export triggers Acrobat 110/117 errors on large tablix reports
SSRS Report / Power BI / PDF Export Issue (Not sure if it’s VS’s report designer or Power BI that’s causing this so I’m putting it here):
Using VS 2026, Microsoft Reporting Services Projects 4.0.0, Power BI Report Server 1.26.9682.1442 (May 2026)
I have this SSRS report (designed with Microsoft Reporting Services Projects 4.0.0) with a tablix that has nested row groups published on a Power BI server. When the report gets over about 2500 records (~220 pages maybe) the report still generates. But when I save as PDF from the report viewer, it does produce a fine PDF but when any changes are saved in it from Adobe Acrobat, we’ll either get error code 110 “Unrecognized object name” or 117 “Non-hex character in a hex string”.
I found it’s not because of specific records because when I made it retrieve 2500 records it worked, when I made it retrieve 4000 records it produced a corrupt PDF, but when I had the report’s SQL query skip the first 2500 records and get only those 1500 records that apparently corrupted the PDF, it produced a noncorrupt PDF. This has been confirmed with other records as well.
I’ve tried every combo of row group, cell, and tablix settings that were half reasonable to try. I’ve added in and stripped out accessibility features. I fixed all warnings given when deploying the report. It’s always the same thing, it’s fine until over about 2500 records.
We need the PDF to be editable after generation; I’ve exhausted every option. If anyone knows how to fix this that’d be great.
Hi nelsonj,
Thank you ShivekMaharaj, for your insights.
Since the same large report works correctly when exported locally but runs into issues when exported through PBIRS, I’d focus the investigation on the PBIRS-side rendering environment rather than on specific records in the report. Reproduce the issue and compare ExecutionLog3 and the Report Server trace log to see if there are any rendering errors, warnings, or resource-related issues. Microsoft also notes that PDF rendering processes the entire report in memory, so it would be worth checking the server’s resource usage while reproducing the issue before making any PBIRS memory configuration changes
Use ExecutionLog and the ExecutionLog3 view in Reporting Services - SQL Server Reporting Services (SSRS) | Microsoft Learn
Report server service trace log - SQL Server Reporting Services (SSRS) | Microsoft Learn
Configure available memory for report server applications - SQL Server Reporting Services (SSRS) | Microsoft Learn
Report and snapshot size limits - SQL Server Reporting Services (SSRS) | Microsoft Learn
Thank you.
6 Replies
v-saisrao-msftCommunity Support
Hi nelsonj,
Checking in to see if your issue has been resolved. let us know if you still need any assistance.
Thank you.
- v-saisrao-msft
Hi nelsonj,
Have you had a chance to review the solution we shared earlier? If the issue persists, feel free to reply so we can help further.
Thank you.
- ShivekMaharaj
Community Champion
Hi nelsonj,
Your subset test is actually a very useful clue. If rows 1-2500 produce a valid PDF, rows 1-4000 produce a corrupt PDF, and rows 2501-4000 also produce a valid PDF by themselves, I would stop looking for a specific "bad" record.
I also couldn't find a documented SSRS/PBIRS row limit around 2500 for PDF exports. The PDF renderer is a physical-page renderer, so a ~220-page nested tablix can exercise the renderer very differently from the HTML report viewer.
Your PBIRS version 1.26.9682.1442 is already the current May 2026 build listed by Microsoft, so I would not expect a simple server upgrade to resolve this unless Microsoft releases a subsequent fix.
I would try two isolation tests next:
- Run the same 4000-row RDL locally in Report Builder and export it directly to PDF. If local PDF works but the PBIRS export is corrupt, that points much more strongly to the server-side rendering environment/build.
- Export the same large report from PBIRS to another format such as Word. If Word succeeds consistently while only PDF is corrupt, that narrows it further to the PDF rendering extension.
On the server, I would also compare a successful and corrupt export in ExecutionLog3, particularly Status, RowCount, ByteCount, TimeRendering and AdditionalInfo.If the corrupt export is still recorded as rsSuccess, I would capture that execution together with the corresponding ReportServerService trace log and open a Microsoft support case. That would be strong evidence that report processing completed but the generated PDF itself was malformed.
I would check memory pressure in the server logs as well, but I would avoid changing Reporting Services memory settings until the logs show evidence that memory is actually involved.
Given the clean subset test, this looks much more like a scale/rendering issue than a particular record in the dataset.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
Hi ShivekMaharaj, thanks very much for responding! Yes indeed after I posted this I ran and saved a large PDF from the report locally on Friday and lo and behold it came out not corrupt. So it must be an issue with the report server. It's on premise and we can adjust anything with it -- any idea what we could adjust?
- ShivekMaharaj
Hi nelsonj,
That local 4,000-row export is a really useful result. Since the full report exports correctly from Report Builder but becomes corrupt only when rendered through PBIRS, the server-side rendering path now looks like the main area to isolate.
Before changing any Report Server memory settings, I would try one more test: render the same report directly through the Report Server URL using rs:Format=PDF, rather than exporting it through the PBIRS portal. Microsoft documents this direct URL rendering approach.
If that PDF is also corrupt, it points much more strongly at the server-side renderer/execution path. If the direct URL produces a valid PDF while the portal export is corrupt, I would then look more closely at the portal/download path or anything sitting between PBIRS and the client.
I would also compare TimeRendering, ByteCount, and AdditionalInfo in ExecutionLog3 between a successful smaller export and the failed full export.
One reason I would hold off on changing RSReportServer.config for now is that Microsoft notes the memory-management settings do not improve report-processing performance by themselves and are mainly relevant when requests are being dropped under memory pressure.
That direct URL test should narrow this down quite a bit.
AI-assisted drafting: AI was used to help structure and phrase this response. I reviewed and validated the technical content before posting.
