ASP.NET randomly loses session values

Question

I have been looking for answers to this for quite some time, as it continues to hurt me. We store user login data and other data about current user activities in session state (InProc). Each time I get a Null Reference exception, trying to use one of the session variables. This happens on random pages with random session variables. I changed the web.config httpRuntime and matching tags to prevent appPool from restarting:

<httpRuntime requestValidationMode="2.0" waitChangeNotification="86400" maxWaitChangeNotification="86400" /> <compilation debug="False" strict="false" explicit="true" targetFramework="4.0" numRecompilesBeforeAppRestart="1000" /> 

I installed IIS to restart the application pool at 3am to make sure it does not restart when people are busy on the server. And I am registering the application pool in the event log to make sure that I know when this happens.

 Dim runtime As HttpRuntime = GetType(System.Web.HttpRuntime).InvokeMember("_theRuntime", BindingFlags.NonPublic Or BindingFlags.Static Or BindingFlags.GetField, Nothing, Nothing, Nothing) Dim shutDownMessage As String = runtime.GetType().InvokeMember("_shutDownMessage", BindingFlags.NonPublic Or BindingFlags.Instance Or BindingFlags.GetField, Nothing, runtime, Nothing) Dim shutDownStack As String = runtime.GetType().InvokeMember("_shutDownStack", BindingFlags.NonPublic Or BindingFlags.Instance Or BindingFlags.GetField, Nothing, runtime, Nothing) Dim evtSource As String = "ASP.NET" Dim log As New EventLog log.Source = evtSource log.WriteEntry(String.Format("_shutDownMessage={0}{2}_shutDownStack={1}", shutDownMessage, shutDownStack, vbCrLf & vbCrLf), EventLogEntryType.Warning) 

I get event log entries when the application pool restarts. The application pool does not restart when these errors occur.

When certain session variables are lost, most other session variables for the same user still exist. In addition, as a rule, another 10-20 users register on the site, which are not affected when this happens.
The user who receives the error message will back up, repeat the same pages, and it will work normally.

I had this problem on Windows Server 2003 (32-bit) with IIS6 with .NET 3.5 32-bit and 4 GB of memory. As part of our server updates, about a year ago, we received a new web server - Windows Server 2008 (64-bit) with IIS 7 with 16 GB of memory. I upgraded the site to .NET 4.0 64bit. The same problems still occur on the new machine (usually 1-3 times a day - randomly during the day).

I cannot do this in my debugging due to its random nature, but I am sure that this happens randomly in our development environment. The dev server has almost the same characteristics as the production server. Both environments are isolated and run as a single web server, not part of a web farm.

I think I can try to implement State Server to exit InProc mode, but this is just another hit in the dark.
Besides trying the status server, is there anything else I can do to determine when this will happen or to prevent it?

Answer 1

For those interested or dealing with similar issues, I would like to follow the causes of my problem here.

I implemented an out-of-process NCache state server for the application cache and session state about 7 or 8 months ago. Unfortunately, moving the session out of the process did not affect my problem of losing random session variables while selecting a report on my site. And, since I could not reproduce this problem, I did not make any more efforts, trying to fix it until recently, when another problem made the light go into my head.

To get to the point - I did not rewrite the session variables somewhere that I did not understand, but the problem was that the user opened a second (or third) tab to compare the options for selecting a report side by side. We have several custom reports in which the user can select several options for creating their own reports (think of it as a management wizard, where there are several steps for creating a custom report). If the user is in step 3 of 5, and then opens a new tab and starts the process of selecting the report again, the new selections overwrite the old b / c options that the 2 tabs use the same session. I checked this by opening several tabs and stepping through the selection process.

I am trying to distinguish between several report runs so that the selection for one report is stored using a unique session key from other report parameters. This is also difficult, but not really related to the problem with which I thought I had no session data.

If someone finds this post and thinks that they accidentally lose session data and cannot replicate it, try debugging your site and opening several tabs. At the same time, sifting through both tabs, I highlighted the problem for me.

NTN

Answer 2

if your web application is deployed on a server farm (more than one server) As you said, you are using an InProc session, and it may happen that the user is redirected to another server from where it was saved by this session variable. In this case, you should go to the proc session, as you mentioned (Session State Server)

if you are going to the status server, remember below to prevent any other problem:

Since Stateserver combines the ASP.NET session identifier with the IIS application path to create a unique key, sessions issued for one of five new web pages could not be found when accessed through one of the other networks, which are obviously extremely unsuccessful in a round-robin web farm balancing balancing

http://www-jo.se/f.pfleger/session-lost

Also look at this logger to see if the application can be processed against your will:

http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx

http://blogs.msdn.com/b/tess/archive/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles.aspx

Answer 3

The sessional problems you encounter can occur for several reasons.

• Session Duration: Since you are using Inproc mode, sessions are valid only for the time period of a session. which is 20 minutes by default. try using the sessionstate tag in the system.web section of your web.config and set the timeout value to a larger value.

• Another issue may be raised by websites and web gardens. if you set up web farms and a web garden for your website. Sharing an Inproc session can cause problems.

• Restarting the process: the w3p process of your website has been restarted due to some problem in the code. or memory leaks.

Answer 4

I ran into this problem because our server was configured to run https. Sessions will not be saved if I work under simple http. However, the sessions were saved while working on https. Therefore, we configure the URL rewriting rule to always send the application to https if they are logged in via http.

In addition, the sessions will not work locally or on the server if you are not using https (note the S at the end of https), if your web.config file has the following:

 <httpCookies httpOnlyCookies="true" requireSSL="true"/> 

Answer 5

Another condition is where sessions may lose its value.

You can use the Fiddler tool to fix this problem.

The condition itself can be found when you use some element like a source that is not found in the solution. At this point, the server will attempt to reload this unreasonable or lost object by restarting the project. Restarting the project will reset all session objects.

Thanks.

Answer 6

Since it took me a while to figure this out, I thought I'd post it here if this helps someone else.

I came across a situation where both IE and Chrome randomly dropped session variables. I searched and searched, and everyone said the ordinary things ... check the domain name, check the IIS settings for cookies ... etc.

My problem turned out to be a fix.

In my web.config, I have a permissions entry for a “public” folder that an unauthorized publication can access.

 <location path="public"> <system.web> <authorization> <allow users="*" /> <allow users="?" /> </authorization> </system.web> 

The problem was calling the .js public side of the HttpHandler, which was NOT on the public side. In an attempt to reuse the code, I pointed to both the secure and public side of the code in the secure side. I assume this is a side effect, it killed the session without a meaningful error message.

I can add another entry just for this handler, or I can make a public and safe copy of this code (less desirable approach).