I have a .NET 4.5 website where my Session is occasionally disappearing (which, because of my login setup, forces a re-login).
I'm suspecting there is an un-caught error that is killing the Session, but allowing execution to otherwise continue.
My web.config contains the following vanilla-variety sessionState element...
<configuration>
<system.web>
<sessionState timeout="60" />
</system.web>
</configuration>
How can I best go about identifying what is causing the Session to dump, given that there is no visible error message or other bad behavior from the application?
NEW ANSWER
"as I'm making changes".. some changes (i.e. change to web.config) cause an Application Restart (and Session death, of course)!
Look here
if you're running in-process session state, then obviously it's going
to be reset each and every time the application pool is recycled.
Application restarts for:
- Recycle worker processes (in minutes)
- Recycle worker process (in requests)
- Recycle worker processes at the following times
- Maximum virtual memory
- Maximum used memory
- memoryLimit
- requestLimit
- timeout
- Editing and updating
-- web.config
-- machine.config
-- global.asax
-- Anything in the bin directory or it's sub-directories
"A workaround to the sub-directory issue", read it.
OLD ANSWER
Error won't easily kill session even if they're un-caught..
maybe you're facing problems related to page life-cycle (You should be able to access the Session in or after the Page's OnInit event)
or you're facing problems on multi session elements (flash-based file uploader can open a different session)
or you have installed on multiple server your application (each server has his own session!)
could be one of these?
I'm suspecting there is an un-caught error that is killing the Session
In Visual Studio:
Debug -> Exceptions... -> Common Language Runtime Exceptions -> Check the 2 check boxes.
This way, you'll be able to break on any exception.
Related
After a user logs in, I set a Session variable to to store their ID. This ID is used to load things like their user name. The name will show correctly at first, showing that the Session variable was used. However if I refresh the page after just a few minutes, the user name is blank, suggesting the Session variable is now gone.
I've read that the default Session timeout is 20 minutes. I confirmed this in my hosting provider's Asp.net settings. But the variable is lost well before 20 minutes.
I also read that I should have a Global.asax file with the below code:
void Session_Start(object sender, EventArgs e)
{
Session.Timeout = 20;
}
I did that, but I'm still losing the variable after a few minutes. I then read that I should place the below code in my web.config:
<configuration>
<system.web>
<sessionState mode="InProc" timeout="120" />
</system.web>
</configuration>
So I did that, but then it produced an error saying: "Parser Error Message: It is an error to use a section registered as allowDefinition='MachineToApplication' beyond application level. This error can be caused by a virtual directory not being configured as an application in IIS."
I'm not sure what else to try. The website I'm creating is in a sub-directory on my domain, the web.config and global.asax files I edited are in that sub-directory, so I wouldn't think there's a conflict elsewhere right?
Your subdirectory is not marked as an application in IIS. This could be part of the problem as you haven't created the application properly. Since it's not marked as an application, certain features of your web.config are illegal since they can only be placed into the root directory of an application.
Other factors though can be the application pool has recycled for some reason. Sometimes due to errors, but also do to other events such as running out of database connections in the connection pool as well as the most famous which is simply storing too many items in session that causes the app pool to run out of memory and recycle.
Since your application is in a subdirectory, it is actually part of another application. In this case anything going on with the main application could be interfering or abandoning the session. The root web.config could have very different session state settings which could make the behavior very different.
Start by setting the sub-directory as an application in IIS and see how it then behaves. After that, if the problem persists start to look for other issues such as memory leaks. You don't want to keep the session extended for too long either. If a user stops doing anything for more than 20 or 30 minutes, chances are they aren't coming back anytime soon. Since session eats memory, having shorter times helps the performance of the application. If you need longer duration storage, it's generally better for performance as well as the application's stability to use a store made for longer term data such as a database.
I have an ASP.net application where Users aren't able to successfully complete certain actions, for reasons, I'm assuming, can only be related to losing their session (which is where I maintain their current user information, and how determine whether they are logged in)
I'm at a loss as to why they would lose their session, so my first question is:
What (in general) would cause a user to lose their session in ASP.net?
and since I don't know when a user loses their session and can't reproduce it myself:
How can I track when I user loses their session
Below is my sessionState config for reference
<sessionState
mode="InProc"
cookieless="false"
cookieName="My.Site.Com"
timeout="480"/>
A number of things can cause session state to mysteriously disappear.
Your sessionState timeout has expired
You update your web.config or other file type that causes your AppDomain to recycle
Your AppPool in IIS recycles
You update your site with a lot of files, and ASP.NET proactively destroys your AppDomain to recompile and preserve memory.
-
If you are using IIS 7 or 7.5, here are a few things to look for:
By default, IIS sets AppPools to turn themselves off after a period of inactivity.
By default, IIS sets AppPools to recycle every 1740 minutes (obviously depending on your root configuration, but that's the default)
In IIS, check out the "Advanced Settings" of your AppPool. In there is a property called "Idle Time-out". Set that to zero or to a higher number than the default (20).
In IIS, check the "Recycling" settings of your AppPool. Here you can enable or disable your AppPool from recycling. The 2nd page of the wizard is a way to log to the Event Log each type of AppPool shut down.
If you are using IIS 6, the same settings apply (for the most part but with different ways of getting to them), however getting them to log the recycles is more of a pain. Here is a link to a way to get IIS 6 to log AppPool recycle events:
http://web.archive.org/web/20100803114054/http://surrealization.com/sample-code/getnotifiedwhenapppoolrecycles/
-
If you are updating files on your web app, you should expect all session to be lost. That's just the nature of the beast. However, you might not expect it to happen multiple times. If you update 15 or more files (aspx, dll, etc), there is a likelyhood that you will have multiple restarts over a period of time as these pages are recompiled by users accessing the site. See these two links:
http://support.microsoft.com/kb/319947
http://msdn.microsoft.com/en-us/library/system.web.configuration.compilationsection.numrecompilesbeforeapprestart.aspx
Setting the numCompilesBeforeAppRestart to a higher number (or manually bouncing your AppPool) will eliminate this issue.
-
You can always handle Application_SessionStart and Application_SessionEnd to be notified when a session is created or ended. The HttpSessionState class also has an IsNewSession property you can check on any page request to determine if a new session is created for the active user.
-
Finally, if it's possible in your circumstance, I have used the SQL Server session mode with good success. It's not recommended if you are storing a large amount of data in it (every request loads and saves the full amount of data from SQL Server) and it can be a pain if you are putting custom objects in it (as they have to be serializable), but it has helped me in a shared hosting scenario where I couldn't configure my AppPool to not recycle couple hours. In my case, I stored limited information and it had no adverse performance effect. Add to this the fact that an existing user will reuse their SessionID by default and my users never noticed the fact that their in-memory Session was dropped by an AppPool recycle because all their state was stored in SQL Server.
I was having a situation in ASP.NET 4.0 where my session would be reset on every page request (and my SESSION_START code would run on each page request). This didn't happen to every user for every session, but it usually happened, and when it did, it would happen on each page request.
My web.config sessionState tag had the same setting as the one mentioned above.
cookieless="false"
When I changed it to the following...
cookieless="UseCookies"
... the problem seemed to go away. Apparently true|false were old choices from ASP.NET 1. Starting in ASP.Net 2.0, the enumerated choices started being available. I guess these options were deprecated. The "false" value has never presented a problem in the past - I've only noticed in on ASP.NET 4.0. I don't know if something has changed in 4.0 that no longer supports it correctly.
Also, I just found this out not long ago. Since the problem was intermittent before, I suppose I could still encounter it, but so far it's working with this new setting.
In my case setting AppPool->AdvancedSettings->Maximum Worker Proccesses to 1 helped.
Your session is lost becoz....
JUST MAKE SURE THERE ARE NO RUNTIME ERRORS, ANY FATAL EXCEPTION WOULD
KILL THE SESSION!
In Microsoft stack, Visual Studio - put Ctrl + Alt + E - All Exceptions ON, then run the code in Debugging mode. Any Fatal ones are THE reason for session loss..
You could add some logging to the Global.asax in Session_Start and Application_Start to track what's going on with the user's Session and the Application as a whole.
Also, watch out of you're running in Web Farm mode (multiple IIS threads defined in the application pool) or load balancing because the user can end up hitting a different server that does not have the same memory. If this is the case, you can switch the Session mode to SQL Server.
I was only losing the session which was not a string or integer but a datarow.
Putting the data in a serializable object and saving that into the session worked for me.
Had a problem on IIS 8 when retrieving Content via Ajax. The issue was that MaximumWorkerProcesses was set to 2 and Javascript opened 17 concurrent requests. That was more than the AppPool could handle and a new pool (without auth-data) was opened.
Solution was to Change MaximumWorkerProcesses to 0 in IIS -> Server -> Application Pools -> [myPool] -> Advanced Settings -> Process Model -> MaximumWorkerProcesses.
Dont know is it related to your problem or not BUT Windows 2008 Server R2 or SP2 has changed its IIS settings, which leads to issue in session persistence. By default, it manages separate session variable for HTTP and HTTPS. When variables are set in HTTPS, these will be available only on HTTPS pages whenever switched.
To solve the issue, there is IIS setting. In IIS Manager, open up the ASP properties, expand Session Properties, and change
New ID On Secure Connection to False.
I had same problem by losing sessions. every time , every page reload, my sessions clear and by new reload any page, my sessions returned by valid value...
i fixed it by change MaximumWorkerProcesses from 0 to 1 in iis
I was struggling with this issue for 14 days.
Here's what helped me:
Check your recycling options in App Pool > Advanced settings. Turn off all of the options so it won't recycle on its own.
Check your web.config file for the executionTimeout property under httpRuntime and increase its value.
Check your web.config file for the timeout property under sessionState and increase its value (I set it to 300 minutes).
Go to the server's event log and check the Application log for unhandled exceptions that may cause the worker process to crash. Fix them in your code or use try and catch to eliminate this crash.
Try changing the value of your maximum worker process from 0 to 1 or the other way around, this may also solve this issue.
In my case, session state was loosing due to Load Balancer. Session was storing in one server and Load balancer was redirecting next call to another server where session state was missing.
What happen if web.config gets updated while ASP (ASP.NET 2.0) server still process client request?
- Will the process be killed?
- If not, will the process read the updates in web.config.
thanks for any input
The new web.config is effectively a copy, so an ongoing request will finish unaffected -- it will not pick up the changes. When the request is complete, the new web.config will be written over the old one and subsequent requests will work from the updated values (in a new application domain).
Microsoft: "ASP.NET will serve all pending requests before restart"
-- http://msdn.microsoft.com/en-us/library/ms178473.aspx
When an application restart is
required, ASP.NET will serve all
pending requests from the existing
application domain and the old
assemblies before restarting the
application domain and loading the new
assemblies.
and following the flow of logic through changes to the asp.net Web.config file ...
"Configuration Changes Cause a Restart of the Application Domain"
The app effectively restarts. However there is also a trick noted in this first blurb to work around that "issue".
Changes to configuration settings in
Web.config files indirectly cause the
application domain to restart. This
behavior occurs by design. You can
optionally use the configSource
attribute to reference external
configuration files that do not cause
a restart when a change is made. For
more information, see configSource in
General Attributes Inherited by
Section Elements.
Attempts to change a configuration
file by someone who does not have
permission to edit the file will not
cause a restart of the application
domain.
^-- http://msdn.microsoft.com/en-us/library/ackhksh7.aspx
Loss of State
Your application, session and other states will be lost if stored in process ...
When using the in-process
session-state mode, session-state data
is lost if aspnet_wp.exe or the
application domain restarts.
^-- http://msdn.microsoft.com/en-us/library/87069683(VS.71).aspx
The life-cycle implications of
information stored in application
state. The .NET Framework application
domain or the process hosting a
.NET-based application can be torn
down and destroyed at any moment
during application execution (as a
result of crashes, code updates,
scheduled process restarts, and so
on).
^-- http://msdn.microsoft.com/en-us/library/bf9xhdz4(VS.71).aspx
Etc...
Just some miscellanei. Info about storing session state out of process.
^-- http://msdn.microsoft.com/en-us/library/ms178586.aspx
I believe that if you make any changes to web.config, ASP.NET automatically reloads your application by recycling the application pool. This of course will result in Session, Application, and Cache data of an InProc session state being lost.
The AppDomain will be unloaded after the request finishes.
I have an ASP.NET WebSite which restarts in every 1-2 hours in a day so sessions and other thing are gone and users are complaning about it, because they open a page and do something for 20 minutes and when they submit it, a nice "we are sorry" page is there.
I don't do anything which restarts the application (changing the web.config, changing the files, or even other buggy things like deleting a folder in App_Data which normally shouldn't cause a restart).
Can it be related with Server's hardware? It is not much powerful.
I guess this is recycling.
App pools in IIS get recycled by default - either after a timeout, or after "n" hits.
This should be expected, and is part of the normal processing (although it can be disabled in the app-pool configuration; IIS6 | IIS7).
The fact that this breaks your app suggests that you are using a lot of things like in-memory sessions. Consider moving these to database backed implementations. Apart from withstanding both app-pool restarts and server reboots, this can allow you to scale the site to multiple servers.
Check this blog post about some possible causes for appdomain recycles. There are many possible causes.
If you are unable to fix the problem you could switch from in-process session state to eiter a session state server or to storing session state in a database. Both options are easy to set up and works quite well, but there is a performance impact (between 10-20% I think). There is a nice article here about how to setup a session state server.
Sounds like the app is being recycled or process is failing.
Check app pool settings http://msdn.microsoft.com/en-us/library/aa720473(VS.71).aspx
and event viewer.
Since you mention that your server is small, you might check to see if your worker process is consuming more memory that you have set in your processModel in machine.config. That can cause a reset.
Are you sure that the ASP.NET application actually restarts? Or do you think that it happens because of the lost Session and such?
What is your application's (and IIS') Session timeout variable? The default value of the timeout is 20 minutes, so that's why I am asking. You can set the timeout in your web.config as follows:
<system.web>
<sessionState timeout="120"/>
</system.web>
But apart from that, there are also places inside IIS itself where you can set it. In the case of IIS6 those places are:
Properties of a virtual directory > Home Directory (tab) > Configuration (button) > Options (tab) > Session timeout
Properties of a virtual directory > ASP.net (tab) > Authentication (tab) > Cookie timeout
I'm not sure whether or not both are actually needed, but I usually set both to the same value as I set it in my web.config.
Is there any indication of the cause of the restart logged in the Event Log?
Do you have any anti-virus software running on the server. A change to the web.config will cause your application to restart afaik so in some instances anti-virus software passing over the web.config might alter the attributes on the file which could be causing the reset.
Try disable any AV software or exclude the web applications directory from the AV auto scanning.
Here is my current question:
I'm guessing that my problem (described below) is being caused by ASP.NET worker processes being recycled, per the answers below—I'm using InProc sessions storage and don't see much chance of moving away, due to the restriction for other types of storage that all session objects be serializable. However, I can't figure out what would make the worker process be recycled as often as I'm seeing it—there wasn't any changing of the files in the app directory as far as I know, and the options in IIS seem to imply that the process would only be recycled every 1,740 minutes—which is much less frequent than the actual session loss. So, my question is now, what different cases can cause an ASP.NET worker process to be recycled?
Here is my original question:
I have a difficult-to-reproduce problem that occurs in my ASP.NET web application. The application has one main .aspx page that is loaded and initializes a number of session variables. This page uses the ASP.NET Ajax Sys.Net.WebRequest class to repeatedly access another .aspx page, which uses the session variables to make database queries and update the main page (the main page is never re-requested).
Occasionally, after a period of time using the page, causing successful HTTP requests where the session created in the main page properly carries over to the subpage, one of the requests seems to cause a new ASP.NET session to be created—all the session variables are lost (causing an exception to be thrown in my code), and a new session id is reported in the dynamically requested page. That means that suddenly, the main page is disconnected from the server—as far as the server is concerned, the user is no longer logged in.
I'm nearly positive it's not a session timeout—the timeout time is set to something ridiculous, the amount of time it takes to get this to happen is variable but is never long enough to cause the session to time out, and the constant Sys.Net.WebRequests should refresh the session timer.
So, what else could be happening that would cause the HTTP requests to lose contact with the ASP.NET session? I unfortunately haven't been sniffing network traffic when this has happened to me, or I would've checked if the ASP.NET session cookie has stuck around or not.
One solution would be to use a StateServer, rather than InProc session management.
Lots of things can cause the session state to be lost:
Editing Web.Config
IIS resetting
etc.
If the session state is important to your app then use either SQL state management, or the State Server which ships with ASP. NET.
Cheers,
RB.
We had problems of Session when we did migrating the AnkerEx application to the
new server. The new server had Microsoft Windows Server 2008 as operation system
and Microsoft Internet Information Services 7. Also in the server were installed
.NET Framework of versions 1.0.3705, 1.1.4322, 2.0.50727, 3.0 and 3.5.
For solving of this problem i have done enabling health monitoring for
application's Lifetime related events in ASP.NET 2.0. I had added to the web.config:
...
...
<system.web>
...
...
<healthMonitoring>
<rules>
<add name="Application Events"
eventName="Application Lifetime Events"
provider="EventLogProvider"
profile="Default"
minInterval="00:01:00" />
</rules>
</healthMonitoring>
...
...
It is help to us to check the AppDomain recycles. We can see it at our Event Viewer.
The link to more details is http://blogs.msdn.com/rahulso/archive/2006/04/13/575715.aspx
After I have done adding to web.config, the Event Viewer showed me that my
application is restarting every time when i do click to almost any link in my
application.
From the article of http://blogs.msdn.com/toddca/archive/2005/12/01/499144.aspx i
found out that ASP.NET has the new behavior - if we will do deleting, for example
a sub-directory of the application's root directory, then ASP.NET 2.0 will do the
restarting AppDomain.
The problem was in that that I had in the web.config the instruction:
...
<compilation debug="true" tempDirectory="c:\AnkerEx\Temporary ASP.NET files">
...
I.e. the ASP.NET did compiling of aspx pages in folder of my application root.
I think he created folders, may be and did removing some of them also. I removed
tempDirectory instruction and the application began work stable.
The worker process is probably cycling.
http://www.lattimore.id.au/2006/06/03/iis-dropping-sessions/
It could be caused by an unhandled exception in a background thread. It can cause your ASP.NET worker process to terminate. A new process is started very quickly so you don't actually notice it but all your sessions are lost.
Here is an article that explains it much better than I can: ASP.NET 2.0 Unhandled Exception Issues
quote:
An unhandled exception in a running ASP.NET 2.0 application will usually terminate the W3WP.exe process, and leave you with a very cryptic EventLog entry something like this:
"EventType clr20r3, P1 w3wp.exe, P2 6.0.3790.1830, P3 42435be1, P4 app_web_ncsnb2-n, P5 0.0.0.0, P6 440a4082, P7 5, P8 1, P9 system.nullreferenceexception, P10 NIL."
Here is a Microsoft KB article that explains the same issue: KB911816 Unhandled exceptions cause ASP.NET-based applications to unexpectedly quit in the .NET Framework 2.0
My guess would be memory consumption - but, set up IIS to log recycles and you'll know for sure.