Application getting logout frequently - ASP.NET session has expired or could not be found - Microsoft.ReportViewer.WebForms

Rupesh Musale (Ext) 0 Reputation points
2024-12-05T08:06:48.54+00:00

Dear all,

we are getting below error frequently from few days without any deployment on production environment, unable to find the solution. even after increasing session time out and tried various suggestions on internet still facing the same issue. kindly guide us on this.

Message ---

{0}ASP.NET session has expired or could not be found

Source ---

{0}Microsoft.ReportViewer.WebForms

StackTrace ---

{0} at Microsoft.Reporting.WebForms.ViewerDataOperation..ctor()

at Microsoft.Reporting.WebForms.HttpHandler.GetHandler(String operationType)

at Microsoft.Reporting.WebForms.HttpHandler.ProcessRequest(HttpContext context)

at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()

at System.Web.HttpApplication.ExecuteStepImpl(IExecutionStep step)

at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

TargetSite ---

{0}Void .ctor()

Thank you

Windows development Internet Information Services
SQL Server Reporting Services
SQL Server Reporting Services
A SQL Server technology that supports the creation, management, and delivery of both traditional, paper-oriented reports and interactive, web-based reports.
3,061 questions
Windows for business Windows Server User experience Other
Developer technologies ASP.NET Other
Developer technologies C#
{count} votes

1 answer

Sort by: Most helpful
  1. Albert Kallal 5,586 Reputation points
    2024-12-05T17:44:14.8733333+00:00

    I'm going to suggest you try SQL server based session(), or even easier is to turn on the state server, and try that. Session() can become VERY flakey if some code triggers an error, and that will OFTEN result in session() going out of scope. In other words, this probably is not a session() timeout, but some code and library triggering a code error. When that occurs then session() will often be lost.

    So, you can spend a lot of time trying to track down "some" error in "some" place that is un-handled, and thus in most cases it simply better to make session() more robust.

    Give "state server" sessions a try, see if that helps.

    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.