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.
Windows for business | Windows Server | User experience | Other
Developer technologies | ASP.NET | Other
Developer technologies | C#
Developer technologies | C#
An object-oriented and type-safe programming language that has its roots in the C family of languages and includes support for component-oriented programming.
{count} votes

1 answer

Sort by: Most helpful
  1. Albert Kallal 5,591 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' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.