Forum Discussion

nelsonj's avatar
nelsonj
New Member
26 days ago
Solved

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.

pdf export
SSRS
tablix

6 Replies

  • v-saisrao-msft's avatar
    v-saisrao-msft
    Icon for Community Support rankCommunity Support
    16 days ago

    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.

  • v-saisrao-msft's avatar
    v-saisrao-msft
    Icon for Community Support rankCommunity Support
    13 days ago

    Hi nelsonj​,

    Checking in to see if your issue has been resolved. let us know if you still need any assistance.

    Thank you.

  • ShivekMaharaj's avatar
    ShivekMaharaj
    Icon for Memorable Member rankMemorable Member
    25 days ago

    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:

    1. 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.
    2. 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.