SSRS UnhandledReportRenderingException

Question

Current environment:
SSRS: 16.0.1115.92
SQL Server instance: Microsoft SQL Server 2019 (RTM-CU26) (KB5035123) - 15.0.4365.2 (X64)

Enterprise Edition (64-bit) on Windows Server 2016 Datacenter 10.0 <X64> (Build 14393: ) (Hypervisor).

When we migrated SSRS from 16.0.1115.61 (2024-01-23) to 16.0.1115.92 (2024-05-01) a subscription started failing with below unhandled exception:

reportrendering!WindowsService_9!2dc0!05/13/2024-10:19:47:: e ERROR: Throwing Microsoft.ReportingServices.ReportProcessing.UnhandledReportRenderingException: , Microsoft.ReportingServices.ReportProcessing.UnhandledReportRenderingException: An error occurred during rendering of the report. ---> Microsoft.ReportingServices.OnDemandReportRendering.ReportRenderingException: An error occurred during rendering of the report. ---> System.InvalidCastException: Unable to cast object of type 'Microsoft.ReportingServices.ReportIntermediateFormat.RecordField' to type 'Microsoft.ReportingServices.ReportIntermediateFormat.RecordRow'.

and writing out a dump file:

library!WindowsService_9!2dc0!05/13/2024-10:19:47:: e ERROR: Report server dump occured. Exception: Microsoft.ReportingServices.ReportProcessing.UnhandledReportRenderingException: An error occurred during rendering of the report. ---> Microsoft.ReportingServices.OnDemandReportRendering.ReportRenderingException: An error occurred during rendering of the report. ---> System.InvalidCastException: Unable to cast object of type 'Microsoft.ReportingServices.ReportIntermediateFormat.RecordField' to type 'Microsoft.ReportingServices.ReportIntermediateFormat.RecordRow'., Message: , Unhandled Exception: False library!WindowsService_9!2dc0!05/13/2024-10:19:47:: e ERROR: Report server unique dump occured. Exception: Microsoft.ReportingServices.ReportProcessing.UnhandledReportRenderingException: An error occurred during rendering of the report. ---> Microsoft.ReportingServices.OnDemandReportRendering.ReportRenderingException: An error occurred during rendering of the report. ---> System.InvalidCastException: Unable to cast object of type 'Microsoft.ReportingServices.ReportIntermediateFormat.RecordField' to type 'Microsoft.ReportingServices.ReportIntermediateFormat.RecordRow'., Message: , Unhandled Exception: False library!WindowsService_9!2dc0!05/13/2024-10:20:30:: i INFO: Dump result: Timeout waiting for external dump process 11952.

Any help will be much appreciated.

Answer 1

1. Check Report Rendering Format: Ensure that the rendering format specified in the subscription matches the format you’re using when saving the report to a file. If you’re getting a delivery error, consider using the File Share delivery extension instead of Report Server E-mail.
2. Impersonation Error: The error message indicates an impersonation error using the security context of the current user. Make sure the account and password for the file share are correct. If you’re exporting to an Azure File Share, verify the account credentials
3. Dump Files: The dump files can provide additional information about the issue. You might want to analyze the dump files to understand the root cause. Look for any specific details or exceptions in the dump files that could help pinpoint the problem.
4. Log Files: Check the SSRS log files for further troubleshooting. The log files can be found in the directory: C:\Program Files\Microsoft SQL Server\MSRSXX.SQL2012\[&Reporting Services\LogFiles&] (or a similar path depending on your SQL Server installation). Look for log files starting with “ReportServerService_” followed by the date and time
5. Monitoring Subscriptions: You can monitor subscription errors using SQL queries. For example, you can count the number of subscriptions with different status codes in the ReportServer.dbo.[Subscriptions] table. This can help identify patterns or recurring issue

Answer 2

Hi Aakash,

1. Rendering format is Excel in both cases (subscription & manual export to a file). Delivery method is 'email' for the subscription. When I export the report in question manually to Excel file it works fine, no rendering issues.
2. Impersonation. Sorry, I don't think this is the case.
3. Dump file is a binary file, I'm not sure how to read it.
4. Log files. Snippets in my posting ARE from log files from the folder you mentioned.

The report has three Row Groups; and dataset has a few top level groups. I noticed that if I include only one top level group into subscription it might succeed. So I split original subscription into a few ones, one for each top level group. Half of them went through just fine, another half failed. So, if it were security or some configuration issue then all of them would fail. It does look like SSRS internal code can't gracefully handle some edge/unusual flows during rendering in subscription.

Environment is SSRS instance on-prem, no Azure or other cloud provider involved.

And the report, and its subscription, haven't been changed for years, and been running for years until we applied latest patch. So frustrating.

Answer 3

Hi @Alex M,

You are using SQL Server2019, but the version for SSRS is SSRS2022, will it be compatibility issue?

Answer 4

Hi @ZoeHui-MSFT ,

The System Requirements section for SSRS 2022 (16.0.1115.96) states following:

SQL Server Database Engine (2014 SP3 or later), to store the report server database

Besides we upgraded from SSRS 2019 to SSRS 2022 back in March, and everything was fine since then until we applied latest patch earlier this month, May 2024.
And if it was compatibility issue, as you suspect, wouldn't it have wider impact? We have dozens of reports and many of them have subscriptions. None of them have any issues except this particular subscription. And even that subscription has been running smoothly for over a month on SSRS 2022 until the patch.

Many reports were created years ago and haven't been modified since then, so maybe you are right and it is a compatibility issue, but then why did it wait to manifest itself for a month and a half and only for one subscription of many.

Answer 5

@ZoeHui-MSFT , we had SSRS 2022 and SQL Server 2019 running alongside each other without any issues for month and a half, so it doesn't look like a compatibility issue. Otherwise we would have run into it right away.