Honestly speaking, since everything works fine most of the time, we never really bother to think about it in detail. When a session loss issue happens on your happy website (for example your customer added 25 items in his cart and when he proceeded to check out he was redirected to the login page!) you end up with not so happy customer(s) and bosses at the same time since it could effect the business quite drastically.

Solving a session loss issue can be really tricky at times. My favorite way to isolate the root cause is to ask relevant questions whenever you face this issue and then fix the root cause. Here is how I typically start asking questions whenever anyone tells me that he is facing certain Session Loss issues.

Question 1: When you say it is a Session Loss, what actually happens? Does the person browsing the website get logged out all of a sudden and he gets re-directed to the Login page (OR is it something specific he does which logs him out)?

Answer 1: Varies, since it is an open ended question.

Inference> At this point, it could be a session timeout issue or a session loss or anything else for that matter! The only thing which is certain is that we need to ask a lot of other questions and narrow the issue down to something which we could fix.

In comes Question 2: Is the issue random? Can you reproduce it at will?

Answer 2: Let us say the answer is YES, it is Random (this is the case mostly). I would jump to Question 3. If it is reproducible, I become quite happy and jump to Question 4. Basically, if the issue is reproducible, you will have quite a few ways in which you can fix it which is good. The unfortunate part is that you might have to go with trial and error, which could be painful.

Inference> Without even doing anything, we now have a few areas to look at depending on whether the issue is reproducible or not. Have a look at the next questions.

Question 3: At this point we know that the issue happens randomly. So, I am now keen to find out if all the users get logged out at the same time, it is problem with just some client(s) OR all the users faces this problem randomly.

Answer 3: To me it is one of the most important questions. I will tell you why.

Let us say he says “Yes,” all the users get logged out sporadically at the same time.
Inference> That would mean that there are two possibilities now at a broader level. The Application Domain is getting recycled for some reason OR the worker process (aspnet_wp.exe > in XP or 2000 box OR w3wp.exe > in 2003 box) is crashing.

The question now is… how you will find it out if it is…

AppDomain restart?

You can add a Perfmon counter and monitor your server as follows…

Click Windows Start button -> Run. Type Perfmon and click Ok.

Expand Performance Logs and Alerts.

Right click Counter Logs and select New Log settings.

Type a name and click Ok.

Click on Add Counters button.

From the Performance object select ASP.NET v.1.1.4322 or the ASP.NET version of your application.

Choose Select counters from list and select Application Restarts.

Click Add, Close, and Ok.

You will notice that the Perfmon will start logging data into this log file.

Once the issue happens (I mean all the users get logged out), right click on your Counter Log file and click Stop.

If you right click and choose properties, it will show you the path where the log file is stored. By default, it is C:\Perflogs, but you can change it.

Notice the path, go to System Monitor in the left pane and click View Log Data in the right pane.

Add the Log file using Add button and click Ok.

Click on Add Counter (+) button, select Application Restarts counter and click on the Add button. Click Close.

Basically, we are checking if the ASP.NET applications are starting for any reason. If it is doing so, you will see a value > 0 and your graph might look like a single (or multiple) step (s) in a staircase.

Figure 1


I have reproduced the Application Restart by touching web.config of my Application a few times. Notice the graph has steps. Also, notice that I have changed the Graph of Perfmon to 10 and the scale for the Counter is set to 1,000 so that the graphical representation makes more sense
 
If you see this, it means that your ASP.NET application is restarting because of a web.config change, a machine.config change, global.asax change, your application’s bin folder change or multiple changes in your aspx files. If that is the case, check the following scenarios.

Any Anti-Virus software

Excluding your Framework and Application folder from Anti-Virus options if the best approach in my opinion.

Any back up software or Indexing service running on your box. It is because they cause FCN (File Change Notification) for the Web Application folder. You can either disable your backup software and Indexing Service completely or exclude the Web Application folder (if your software provides you that option).

Group Policies

Deleting ASP.NET 2.0 Application Sub Directories.

From my personal experience I have seen that even if you are uploading multiple files from the client’s end to your server, you may end up losing your session. An easy resolution is to store the uploaded content outside of your Application folder.

Session loss after migrating to ASP.NET 2.0

Lost session variables and AppDomain recycles

If you see that the App Domain recycle is still happening for some mysterious reason and you have followed the steps 1-6 above, it is time to change to Out of Process session mode like ASP.NET State server. You can move to SQL state management as well, but for the troubleshooting sake, ASP.NET State Server suits just fine. See if that helps. To know more about out of process session mode, check this.

If you are using ASP.NET 2.0, you have a better way to check for the Application domain recycle and the pain of creating a Perfmon log could be avoided pretty easily. Check out Health Monitoring for Application's lifetime related events.

A crash?

Check your Event Viewer and see if you are getting an Error in your Application Log with an Event ID 1000. For more information on Crash and how to fix it please check my blog entry http://blogs.msdn.com/rahulso/archive/2006/03/02/541737.aspx. You may also refer to Tess’s blog to find out more about how to troubleshoot crash related issues.

A simple recycle of the worker process because of the Application Pool related settings (if you are using 2003 Server)?

Ensure that you have disabled all the recycling options for your worker process. By default, your application pool (in IIS 6) is configured to recycle every 29 hours or 20 minutes of inactivity. Who knew your session recycle for all the users is related to these settings? To know more about IIS 6 application pool’s health related configuration, please check the following article. 

Let us say he says, “No,” it is a problem with some users sporadically.

Hmmm, in this case things get trickier. Now, you will need to find out if it is a problem with a specific user or multiple users (not simultaneously though). Let us say there is 1 specific user who sees this issue quite often. What would that imply? Well, as you might have guessed, it could be something related to some client side settings or actions. You might like to ask the following questions and start making certain conclusions and isolating the issue further.

Does the client face the same problem with a specific machine on his end?

Maybe he has not tried to visit the same website from multiple machines. If possible, ask him to try doing it from a different machine (for example, if the customer is using Win XP, ask him to check it on a different WinXP AND Win 2k3 box as well). It could be something specific to his machine settings. We could have checked his machine settings as well, but why waste time in checking the stuff if you do not have enough proof that it is a problem with that specific machine? If the end user says that the issue persists only with his Box then you have a reproducible scenario and you have drilled down to a piece of hardware/software which could be causing that issue. Good job so far!

Now, how do we say that it is a problem with the hardware (network wire/router/etc etc) or software (browser settings/policies on his box)? I would suggest using a separate browser, say Mozilla and have him check it. If you find that Mozilla browser works perfectly, it HAS to be one of the settings in his Internet Explorer. Start with Cookie related settings and check you are not running out of space in Temporary internet files, number of cookies, etc. There is tool called Fiddler (it is an HTTP Debugging Proxy tool) which could help you check the settings at the problematic client. You could also use Network Monitor to get network traces and find out about what is going wrong. I have a blog entry which talks about how to fix cookie related issues.

Maybe there is a problem with the User’s account in your code (if your code checks that specific user to be good/bad depending on some criteria). You should be able to check those things using regular ASP.NET Tracing or regular debugging techniques based on your application architecture.

Let us say he says, “All the users face this problem but not at the same time.”

Okay, in this case you can easily guess that there could be some problem with the Server. Now, since you have already proven that AppDomain is not getting recycled and Worker process is also not dieing, what could be the problem?

Notice… it is not a problem which “All the users face at the same time.” It is something which is happening to ALL the users, BUT NOT AT THE SAME TIME.

Let us see what happens when you have a web farm. Assume I am the client and hitting your server X. My session is known to the server X. Next time I hit the same box X and everything is fine. After about 10-15 minutes, that server is under load and I am redirected to the Server Y. Naturally, Y will not know who I am and would simply redirect me to the login page. And the same thing would happen to any person who hits your website. In this case, we will have to use Out of Process session mode, which could be ASP.NET State Server or SQL Server.  Imagine what would happen if you still end up losing sessions?

I would suggest checking the following.

1. In IIS, the Web sites names and identifiers must be same throughout the web farm (NOTE that it is CASE-SenSitive). For more details, check out the following KB.

2. In your Framework folder (C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\CONFIG) there is a machine.config file which contains the following default settings.

<machineKey validationKey="AutoGenerate,IsolateApps" decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>

If you are planning to use a Web Farm, you must ensure that the machineKey’s validationKey and decryptionKey is not set to AutoGenerate. The following KBs will show you how to do it in VB and C#.

3. If you are not using Web farms, check for Web garden. In your machine.config (pre Win 2k3 servers) there is an attribute called Web Garden which could be enabled to True. If you plan to keep this to true, you must use Out Of process as discussed above. In Win 2k3 boxes the web garden configuration is not read from the Machine.config. Instead, it is taken from your Application Pool settings. Read more.

Question 4: Since it is reproducible, the first thing which I would like to clarify is whether it is a problem with this particular application or all the applications.

Answer 4: Let us consider the following scenarios.

All the applications exhibit the same behavior. It means that no application is capable of persisting the session related information. Oh yes, believe me… this is a possibility!! I have seen this issue happen quite often due to a bad server name. For example, if your server name has an underscore or other special characters in it, you will not be able to persist session or cookie related information. To ensure that you are not hitting this issue, check the following KB and ensure that your server name is correctly formed without any Underscores and other special characters.

Session on all of the pages in your application work fine, but assume there is a page where you are just unable to persist the session information. To me, this means that there might be a bad object which is causing this problem. The first thing I would advise is to create a back up page for the problematic page. Then, you need to comment all the lines which are storing anything in session. Once you are done, your page should work fine. Please check it before continuing. Now, add a dummy session variable and see if that works. Since all the other pages are working fine, I am pretty sure that if you create a dummy session variable that would work. Still, it is good to do this test. Once you have checked the dummy session variable in action, all you have to do is uncomment the lines containing session 1 by 1 (or may be chunk by chunk). Test your page each time after you uncomment the page. Pretty soon, you will come up with a variable which is causing you issues. Fix that object and you should be good!

Recently, I encountered a very interesting issue. The sessions were working absolutely fine. This was a shopping cart application and each time the user browsed to any specific item he was able to add it to the cookies. His session worked fine until he selected the 20th item. It would happen each time without fail and happened for no less or more number of items but 20. I decided to peek into the IIS Logs with the cookie enabled.

I could see that the session ID was showing as following…
ASPSESSIONIDSSAQTADR=PKCFNDFCAJPLBEPHCBJCDNPP.

Each time when he selected a new item it stored a cookie and this was appended to the above cookie list. Interestingly, after 20 items the ASPSessionID was removed and we ended up losing the session. I was thinking about why it would be and then found the following KB. Notice that it talks about a limit of 20 cookies per unique host or domain name. So, the bottom-line is that you can end up losing sessions even though there is a limitation with the client side.

I have been working as an IIS/ASP.NET Technical Lead at Microsoft since 2004 and I have seen quite a lot of session loss related issues. Most of the time, I was able to resolve when I followed the above techniques. I hope that this article comes in handy for you as well.

ASP.NET State Management Overview

Session State

Understanding session state modes + FAQ

Underpinnings of the Session State Implementation in ASP.NET

If the above steps have not been able help you fix your problems, you may seek professional support options from Microsoft. Give us a call and we would be most happy to assist you.

Happy troubleshooting!

Rahul Soni