I had to update an old ASP+COM application for a customer when they went from Windows 2003 to 2008R2. The process, while not 100% painless, was sucessful but one problem remains: the application seems to randomly lose the session state or, at least, the session variable where I save the session's COM object.
Basically, the app works like this:
Login form page -> login page (object is created there and saved in Session("MyObject"), user credentials are checked -> First actual application page (Session("MyObject") is checked at the top of the code).
The Second redirect only happens if the credentials are correct but the object is always created.
However, users are reporting that they are frequently being redirected to the logon form page after entering their credentials.
After some investigation, it seems that the application properly goes through the login page, creates and instance of the COM object and redirect to the first application page. And there, the session variable is empty again and so the user is sent back to the login form.
What's more is that it is by far not systematic: the problem happens rather frequently but definitely not all the time. When it starts, users have to log on 2 or 3 times before they can get through. If the application is recycled, it usually solves the issue for some times although this isn't systematic and this isn't even always necessary.
Anyone has any idea what could be going on here ?
Edit: some extra info:
ASP session handling is active
In no part of the code are errors being silently suppressed. They will go to a log file if they happen somewhere the COM object can catch them or the user otherwise.
No error can be seen in the COM object log file, in the IIS log or in the server's event log.
Tracing the process activity with ProcMon didn't turn up anything special.
Looking at the COM object log file, I clearly see the COM object instance being created, the "LoginUser" method being called from the login page and returning successfully and then the first application page being called and the check for the existence of the object stored in the session failing.
There is a single web server, no server farm.
I did have an asp website that did exactly the same thing in the past. You need to check the log files and see if this application or website is running on it's own dedicated application pool and that the application pool is not being auto recycled due to bad code. If the session is being created then dropped, then pass the initital session value to another session - say Session("MyObject2") and check for that in the main page. If the users are still getting logged off then I am sure that the application pool is being recycled due to too many failures such as a redirect infinite loop or something else.
Edit: One more thing. I used to see such errors a lot when using ASP with MS Access and could never figure that out.
As a debugging exercise, I'd be tempted to log info from the ASP Session events including the session OnStart, OnEnd and abandon. Maybe try and get as much info from the request and then work out a given lifecycle/page flow for sessions and then determine if there is anything in common that occurs when the session is either ended or abandoned.
Also, while looking up the Session_OnEnd event, I came across an article that suggests it behaves weirdly in IIS 7.0 See http://blogs.iis.net/lprete/archive/2009/01/04/session-onend-classic-asp-and-iis-7-0.aspx just in case this might be of use.
Good luck.
Related
I have a simple scenario. in one page of asp.net, I store a some values in session like
session("var") = "some string"
or
session("var1") = object of generic list of string
and then use response.redirect to goto another page.
on other page it shows things fine, but when we press a button to do an action on it, session gets null.
Remember, it doesn't always happen. Just sometimes it does so and other times it works fine. We do this practice a lot to move some values from page to page (by storing them into session and goto other page). We have very big application and all works fine, but from some days, have been having this issue on some sites with some users. Once again, it doesn't always happen. 99% it works fine but few times, we have this issue where session variable is no longer available.
Is there any way to know what is going wrong and where? We do store some other variables in the session as well, they seems fine at that time. only some of the session variables lose their values.
From my research, it seems people blames on the IIS worker process restart or Application Pool recycle. But I believe in such case all the session variables in the application must be voided, not selected few. Right?
also, is there any way to know in code if the pool or worker process was restarted?
thanks
Sameers
Perhaps you're passing domain boundaries. Session is identified by a client cookie, which are usually stored on a per-domain basis. So, for example, a redirect from www.whatever.com to client.whatever.com will cause you to lose the session ID, which will appear to you as "voiding the session". So, be careful about sub-domains too. Going from whatever.com to www.whatever.com is fine, but the other way round, nope.
And yes, unless you're on a web farm IIS, restarting the worker process will kill all the sessions. Unless you store them in a database or something.
I have an ASP.NET application using custom errors. There is one error that occurs that I can't seem to get any information about. When the error happens, it does trigger the custom error page, but for some reason it doesn't trigger Page_Error or Application_Error. If I turn CustomErrors Off completely, I get absolutely no feedback at all. The only feedback I ever have gotten up until now is the redirect to the Custom Error Page.
Scenario: ASP.NET WebForms application. One of the pages has an UpdatePanel with a Submit button. The page works fine. But if I walk away for a while (seems to be 30-60 minutes) and then come back and click the Submit button, nothing happens; no error, no response from the page- nothing. I have not been able to get this to happen while running in the Debugger; it only happens when it is hosted in IIS (7.5). [I've seen other SO posts about this issue but none of the suggestions worked for me.]
When the error happens, with CustomErrors=On or RemoteOnly, the redirect to the custom error page works, and with RemoteOnly, from the server, I get no feedback at all, similar to a remote connection with customerrors=off. I was really hoping for the YSOD error page.
I tried trapping the error in Page_Error by logging the errors to a database, but that didn't work either. I know the Page_Error and the DB portion is working because if I change the submit code behind to do a divide by zero, the error is logged in the DB. Also, the divide by zero error will be displayed to the client with customerrors=off, and with it on it will display the custom error page. But removing the divide by zero error, and then waiting 30 mins or so and trying again, the Page_Error code is not hit, even though it does redirect to the custom error page. I then tried moving the code in the Page_Error to Application_Error, but the exact same thing happens. The forced divide by error works but this seemingly timeout related error does not.
So, are there certain errors that can still trigger the redirect to the custom error page, but will not trigger the Application_Error event?
Thank you John and Sergey! This really was a can of worms. Sergey, you were exactly right- the session timed out. John your idea made me think to look at the Windows Application Event Log rather than trying to track it down in the code. It turned out that my ViewState was expiring when the session timed out, which was set to 20 minutes by default. The exact event log error was:
"Viewstate verification failed. Reason: The viewstate supplied failed integrity check."
Now I was able to manually recycle the app pool and force the error to happen at my leisure which made solving it easier. I wasn't using Session though, at least not on the page in question, so why did this matter? This link was helpful in troubleshooting what was happening.
http://support.microsoft.com/default.aspx?scid=kb;en-us;829743
Buried deep into the article was the following sentence describing a scenario causing the worker process to recycle:
"The application pool is running under an identity other than the Local System account, the Network Service account, or an administrative-level account."
My AppPool is in fact running under a local user account which I created specifically for this purpose. When I changed the AppPool to run with ApplicationPoolIdentity, after recycling the AppPool the ViewState error went away. Then I set the AppPool back to run with the local user account again, gave that account local admin privileges, and this also fixed it. Not wanting to have this user be a local admin, I ended up going with a different solution, which was to generate a machine key for this app so the ViewState MAC is always the same, rather than using the default of auto-generating a new one every time the pool recylces or the session times out. Note this is also what you typically need to do if you have multiple web servers behind a load balancer.
I've implemented a custom session state provider for Oracle in my application. It seems to run smoothly (without errors!), but I'm having trouble retrieving some Session variables when I redirect to another page. But it doesn't happen all the time.
When the Session starts, I load a User object into Session. It stays there, because when the user gets to the starting page (and is authenticated), the app still recognizes him. It has no problem retrieving the User object from Session.
But if I pass a value into Session on one of my pages inside the app, then redirect to another page in order to utilize that Session variable, the new page retrieves null from the same named Session variable. Using the Visual Studio Watch window, I can actually see its value change from "100" (or whatever) to null. I don't get it.
The session provider seems to be working correctly because as I said, I'm able to persist some variables. Does someone know what the reason might be for Session to "lose" a value? Thanks.
If you are doing a response.redirect in the page, that can cause the thread to abort before the Session is written back to the database.
I'm a little confused about the life cycle of the session in ASP.NET, here is my test case.
A user logs in, I save some info to a session variable (e.g. Session["bob"]="bob") then I do an "IIS reset". The user is still logged in, but the session data is null (e.g Session["bob"].ToString() throws a NullReferenceException.
I expected the session data to still be around. Is there something I can do, other than log out the user? I expected the session data to be around as long as the user is still logged in.
Any good links so I grok what's going on, as well as any help with the actual issue is greatly appreciated. I tried to Google this, but wasn't able to frame the question in a way to get what I wanted.
The behavior you are seeing - where the Session contents do not survive an IIS reset event - is due to where the Session values are stored. By default these values are stored within the memory of the ASP.NET "Worker Process", which is the program which runs your ASP.NET web site.
When you perform an "IIS reset" you shut down the entire IIS server, including the ASP.NET Worker Process. This means that the contents of the Session are removed from memory. Your user still appears to be logged in because that is controlled by the cookie stored in their browser. If the cookie is still valid, the login is.
If you wish your Session state to survive an IIS reset (or anything else which causes the ASP.NET worker process to restart) you'll need to store your Session objects in another place. This is fully supported by ASP.NET by using different Session storage "Modes". Read about those in the MSDN article "Session-State Modes".
For a general overview of the Session, check out the "ASP.NET Session State Overview" article on MSDN.
yah its right but some time its happen then session no remove properly at that time
you have to check session like
If Session("username") = nothing then
Response.redirect("~/default.aspx")
End if
I am seeing a very strange problem on one of my production boxes. We have an application hosted in IIS 6 on a single machine with an apache web server in front of it. My application is using ASP.NET Membership for authentication and relies on session state. I am seeing a problem right now where some server requests will hit a null exception when trying to access any session variables, but if the request is retried, the page hits no exceptions and behaves properly.
I believe this has something to do with the Session ID cookie either getting corrupted or lost on the request, but I have no idea what could cause that. The reason I believe this is because it seems like ASP.NET is not seeing the cookie and creating a new session, which would explain why the variables are null. When it gets the exception, it cannot write the new SessionID cookie back to the client, so the client still maintains the original SessionID. Then when the next request is sent, the original SessionID cookie is used, which now ASP.NET finds and is able to retrieve the session state. This is pure speculation, but seems to fit the symptoms.
Also this site is using no other cookies other then the ones required by ASP.NET Membership and ASP.NET Session, so I am well under the cookie limit for IE. The site has been functioning properly for about 8 months and this issue just popped up recently. I have tried IIS resets and actually rebooting the machine, but nothing has seemed to help the problem.
Updates:
Here are some clarifications that were asked for.
1.)Our Apache server is the only thing exposed to the internet. All requests occur over HTTPS to this box. The Apache box then forwards all request past over HTTP to our application server. This is being done for security reasons. We have looked to see if Apache might have been the issue, but there seems to be no error in the Apache logs.
2.)The null exception is occurring when trying to access an object stored in session that the application expects to be there as opposed to the exception happening with the actual session object itself.
We have found the root of the issue. It looks like the IIS meta-base got corrupted on our app server. The best way to fix this issue is to do a clean install of IIS, but because of business constraints, this is not an option for us. So another solution is to actually just create a new App Pool for the application to run under. According to some people with more IIS expertise than myself, this will fix the problem in the short term, but it is very likely that the same thing will happen to this App Pool. So we are required to create new App Pools if this starts occurring again.