We Keep Coding

Session_OnStart() does not fire on the first GET request

I have a weird problem. Can't explain this inconsistent behavior.
Normally I would expect that the first GET request to load my default.aspx to fire the Session_OnStart() event. However, this happens only on the first page load after restarting the IIS. On all subsequent page loads (after clearing cookies), Session_OnStart() does not fire on the first GET request.
The page also makes two other POST requests from the client side through jQuery Ajax. Session_OnStart() does fire for BOTH of these requests on all subsequent page loads (again after clearing cookies).
This is a problem because SessionId is not being set on the first response, rather its being set twice on the subsequent responses to the POST requests. So the application ends up creating two SessionIds for each user. And again this does not happen on the first page load right after the IIS restart, which is the weird part.
it is an asp.net 3.5 website running on IIS 7.

Fired an event in asp.net when Session expired or browser close

i want to fire an event in asp.net when my user session has been expired or i close browser.
actually i want to update some thing in database according to login user when he/she leave the site.

Unfortunately this question is very close to "I want to save my data after computer is turned off"... Very hard and not predictable.
Session termination events are not fired for out of process sessions
Users simply close browsers, logout or turn of machines without any cahnce to notify your site
or even worse - instead of watching ads and actively looking at your site they just leave browser open and go drink, sleep...
Or browsers can crash
Now sometimes you can try to handle unload events for browser... you may have enough time to send response sometime.
Probably most reliable solution is to have heartbeat requests from browser and mark users as active this way (in custom database/storage). Periodically check and mark all users that did not send heartbeat requests for some time...

See the session state events documentation here: http://msdn.microsoft.com/en-us/library/ms178583.aspx

Invalid viewstate error on postback

I am getting the following error when the user tries to submit a form, it only happens sometimes... Not sure how to resolve or what the root cause could be. Any help is appreciated. Please see below for screenshot..
Framework 4.0, IIS7
http://s12.postimage.org/69txogmwr/Untitled.png

Things that I have seen cause this:
machinekeys out of sync in a webfarm
page loads slow and the user posts back before it's finished
page sits idle after partial postbacks and the app pool is recycled
page sits idle, new code is deployed for page/controls, first postback dies due to mismatched controls

Session_End code on browser close

I have a method I need to run on Session_end. Is there any way I can ensure the code runs when a user closes his browser? This may be a dup queston. I saw one response doing a call to ajax unload or something, but I don't want this to fire everytime a user navigates away from a page, just when they close their browser.
Thanks,
~ck

Simple answer: You can't control user's browser. The AJAX solution you mentioned is the closest you can achieve (without a plugin/custom client.) Imagine some Web site could track every time you opened and closed your browser window. Don't you think it would be a privacy issue?
The truth lies in the stateless nature of HTTP. The Web server is out of the picture as soon as it finishes sending the response to the client. After that, all you can rely on is a client side script (which only executes because the client wants it to; and it can easily choose not to run scripts.)

Session_end is unreliable. No matter what you do.
Session_end only fires when you are using inprocess session. If you are using a session state server or SQL session, session_end does not fire.
When using in process session, session_end only fires if you have stored something in session. If you aren't using session, session_end will never fire.
If you are using session and the user closes the browser, session_end will fire when the users session times out. While it will have some of the same settings as the original session, this event will not be tied to a browser since it is the worker process detecting the session timeout and firing the session_end process.

How to investigate why Session() expired and let users know

How to investigate what is causing Session expiry?
I would like to give some advise to end-users who have the following problem with our website:
If Session("xxxx") Is Nothing Then say something.. WHY??
Can I add something to web.config to make sessions last longer or should I read the IIS log files to see why this happens?

First session's are configured in web.config's <sessionState> element.
Also you can pick up session ending event (SessionStateModule.End) but note (1) this only works for in-process session management, and (2) you will need to record (in the session) when requests occur, so you can determine if it was a timeout or some other reason.

I think normally if a user does nothing for a period of time(no page refreshes etc) then the session will expire, otherwise it would just consume loads of resources on the server.
In classic asp there was a timeout you could set, not sure if its still there in asp.net or not.
If you don't want the session to expire while to user is looking at your site you could maybe put a meta refresh into your pages, or be a bit cleverer and use some kind of ajax timer that triggers and does a partial refresh on something

You could put some code in your Global.asax file's Session_End method to help determine what went wrong, assuming you're running your session as InProc.
To increase your session length in IIS6, do the following:
Open IIS
Right-Click your website and choose properties
Choose the Home Directory tab
Click the Configuration button, in the Application Settings section
Choose the Options tab
Increase the Session Timeout value to whatever you want.
Close everything and do and IISReset