ASP.NET 2.0 - Loosing session information

C

cyndi_r2000

Hi Everyone:

I have a web application running on .NET 2.0 under IIS 6.0 and users of
this application seem to be loosing their session randomly - we havent
been able to identify any pattern, except for warnings in the event
viewer that say "A process serving application pool xyz terminated
unexpectedly."

..NET 1.1 is also installed on the same machine -- there are separate
app pools for 2.0 and 1.1 apps.

I have removed the default recycling checks from the app pools in IIS
so that the worker process is never recycled automatically. The
web.config for the web app uses inProc session mode and the relevant
key is:

<sessionState mode="InProc" stateNetworkTimeout=""
stateConnectionString="tcpip=127.0.0.1:42424" sqlConnectionString="data
source=127.0.0.1;user id=sa;password=" cookieless="false"
timeout="65"/>

This behavior started after we migrated the same web application from
1.1 to 2.0.

Thanks for your help in advance,
Cyndi
 
J

Juan T. Llibre

Have you considered changing your sessionState mode from "InProc"
to StateServer or SQLServer ?

If the ASP.NET worker process recycles, and your sessionState mode
is running in-process (Inproc), your session variables will be lost.

If the ASP.NET worker process recycles, and your sessionState mode
is running out-of-process (whether StateServer or SQLServer),
your session variables will not be lost.
 
C

cyndi_r2000

Hi Juan,

Thanks for your reply - we could consider moving to other sessionState
modes but I'm concerned as to why we are suddenly having issues with
inProc mode.

Has someone came across this issue after they migrated their existing
1.1 web apps to 2.0?

Thanks,
Cyndi
 
J

Jim Cheshire

Hi Juan,

Thanks for your reply - we could consider moving to other sessionState
modes but I'm concerned as to why we are suddenly having issues with
inProc mode.

Has someone came across this issue after they migrated their existing
1.1 web apps to 2.0?

Moving to out-of-proc Session state because of this is a bad idea.
What you're seeing in the Event Viewer indicates that you are
experiencing a crash. You need to find out why the crash is occurring.

Can you post the details of this event you are seeing?

The best way to troubleshoot something like this is to get a user-mode
crash dump and use Windbg or another such debugger to determine what
caused it.

Jim
 
J

Juan T. Llibre

re:
I'm concerned as to why we are suddenly having issues with inProc mode.

Has your application's complexity increased ?
Have you coded features which have increased the application's RAM demands ?
Have you decreased the thresholds for application pool recycling ?

You could also try to log the reason for the Application reload, per Scott Guthrie's article:
http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx
so you can take the appropiate countermeasure(s).

The simple global.asax code is in this file :
http://www.scottgu.com/BlogPosts/UnloadAppDomain/UnloadReason.zip
 
J

Jim Cheshire

re:

Has your application's complexity increased ?
Have you coded features which have increased the application's RAM demands ?
Have you decreased the thresholds for application pool recycling ?

You could also try to log the reason for the Application reload, per Scott Guthrie's article:
http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx
so you can take the appropiate countermeasure(s).

The simple global.asax code is in this file :
http://www.scottgu.com/BlogPosts/UnloadAppDomain/UnloadReason.zip

Juan,

Scott is demonstrating how to log app domain restarts. What the OP is
experiencing is a recycle of the process itself due to a crash.
Logging app domain restart reasons won't help. The restart message
will always tell you that the hosting environment initiated a restart
in such situations.

Jim
 
J

Juan T. Llibre

Jim,

re:
Scott is demonstrating how to log app domain restarts. What the OP is
experiencing is a recycle of the process itself due to a crash.

When an ASP.NET process recycles, what effectively occurs is an app domain restart,
if state management is InProc.

An alternate approach would be to use Health Monitoring, if ASP.NET 2.0 is being used:

http://msdn2.microsoft.com/en-us/library/ms178701.aspx

Erik Olson explain another approach here :
http://msdn.microsoft.com/msdntv/transcripts/20031023ASPNETEOTranscript.aspx

Also, check the host escalation policy info at :
http://msdn.microsoft.com/msdnmag/issues/05/10/Reliability/
 
J

Jim Cheshire

Jim,

re:

When an ASP.NET process recycles, what effectively occurs is an app domain restart,
if state management is InProc.

Juan,

That's kind of true and kind of not. What happens is that the app
domain gets torn down due to the call to ExitProcess. What you would
see in your log is "HostingEnvironment caused shutdown". There are a
thousand things that can cause that message, so it's of little use in
this scenario.

The proper way to troubleshoot a crash is to use the faulting stack to
track down the problem. If the process is crashing, you already know
why the app domain is shutting down, so logging that isn't going to
tell you anything at all.

Jim
Jim Cheshire
Jimco Software
http://www.jimcosoftware.com
Add-ins for Microsoft FrontPage

Author of
Special Edition Using Microsoft Office FrontPage 2003
 
J

Juan T. Llibre

re:
That's kind of true and kind of not.

Actually, it's true all the time.

When an ASP.NET process recycles, if state management is InProc,
the app domain will, invariably, restart.

That's why I qualified the statement with "effectively".

re:
There are a thousand things that can cause that message,
so it's of little use in this scenario.

True, but other suggestions were made which address your concern:

---000---
An alternate approach would be to use Health Monitoring, if ASP.NET 2.0 is being used:

http://msdn2.microsoft.com/en-us/library/ms178701.aspx

Erik Olson explains another approach here :
http://msdn.microsoft.com/msdntv/transcripts/20031023ASPNETEOTranscript.aspx

Also, check the host escalation policy info at :
http://msdn.microsoft.com/msdnmag/issues/05/10/Reliability/
---000---

The first 2 links have valuable information which can help pinpoint
the reason(s) an ASP.NET worker process is being recycled.

Of course, as you point out, using the faulting stack to track down the problem,
is 100% correct, although it might not be as easily implemented as health monitoring is.

Could you outline the process ?
 
J

Jim Cheshire

The first 2 links have valuable information which can help pinpoint
the reason(s) an ASP.NET worker process is being recycled.

Of course, as you point out, using the faulting stack to track down the problem,
is 100% correct, although it might not be as easily implemented as health monitoring is.

Could you outline the process ?

You have to draw a distinction between the app domain restarting and
the process restarting. I know that I'm telling you what you already
know, but for the benefit of others . . .

Application domains may restart because, for example, a config change
takes place. In that case, you can use health monitoring as you've
suggested and log the WebApplicationLifetimeEvent. In the example I've
used here, this would tell you that a config change took place.

The process may restart for many reasons. The case we're dealing with
here is a "terminated unexpectedly" which means that it crashed. When
the process crashes, naturally all app domains will be terminated. If
you were to log the reason for that, it would only tell you that the
hosting environment was shutting down the app domain. Well, that's not
news. We already know that. Therefore, it's a waste of time to write
code and hook up everything to log that information.

As for troubleshooting the issue via a user-mode dump, that is really
the only way to get to root cause. However, it's a skill that takes
years to acquire. There are a couple of specific problems that can be
located quickly if you know how to do it, but the majority of problems
are not so easily located. It requires an in-depth knowledge of
memory, how data structures are laid out, and how to dissassemble call
stacks.

Can I outline the process? A bit. You can check out my blog for some
information on getting started:

http://blogs.msdn.com/jamesche

I haven't added anything there in a while because I've been swamped
writing a new book, but I have written some information that will give
you an idea of what I'm talking about.

Jim
 
J

Juan T. Llibre

re:
However, it's a skill that takes years to acquire.

Yeah. That's what I was trying to establish.
There are no easy answers, and this is one of the toughest ones.

<sigh>

re:
Can I outline the process? A bit.
You can check out my blog for some information on getting started

Thanks...for all of us who are reading this thread.
 
J

Jim Cheshire

re:

Yeah. That's what I was trying to establish.
There are no easy answers, and this is one of the toughest ones.

<sigh>

This is the ONLY way to find out what's going on without guessing. :)

Jim
Jim Cheshire
Jimco Software
http://www.jimcosoftware.com
Add-ins for Microsoft FrontPage

Author of
Special Edition Using Microsoft Office FrontPage 2003
 
C

cyndi_r2000

Hi Jim/Juan,

Thanks a lot for taking the time to explain the whole process - I'm
going to run a user-mode dump as well as Health Monitoring to figure
out the root cause of the crash. Will keep you updated with my
findings.

Best,
Cyndi
 
D

Decide Now

I recently ported a .Net 1.1 Web project to .Net 2.0 Web application
using Microsoft's new Web Application Project.

http://msdn.microsoft.com/asp.net/reference/infrastructure/wap/default.a
spx

I experienced the same issues of Session information being lost during
execution of the Web application under similar circumstances(e.g.
"InProc", etc.).

It appears that during the execution of my ASP.NET application, the
aspnet_wp.exe aborted several time due to its detection of an
"overwhelming number of file changes" in the web application directory.
This was revealed through reviewing a dump of aspnet_wp.exe. This can
happen for a variety of reasons, two of which (in my case) were / are
having a "moderate to large" number of subdirectories in the ASP.NET
application directory, or running antivirus software on the same
machine.

My issue was resolved with a hotfix from Microsoft.

http://support.microsoft.com/?id=911272


Hope it helps.
DN
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top