ASP.NET 2.0 - Loosing session information

[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

 

[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.

 

[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

 

[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

 

[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

 

[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

 

[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/

 

[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

 

[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 ?

 

[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

 

[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.

 

[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

 

[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

 

[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

 

[Decide Now]

Web Application Projects:

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


-------
General Debugging Info:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/h
tml/DBGrm.asp

-------

HotFix:

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


NOTE: You may need to do an IISRESET after installing the hotfix.

 

[Decide Now]

This article lists what are the causes for the application to shut down:

http://msdn2.microsoft.com/en-us/library/system.web.applicationshutdownr
eason.aspx


This article shows how you can get the details about why the appDomain
unloaded.

http://weblogs.asp.net/scottgu/archive/2005/12/14/433194.aspx

-DN