View Single Post
  #7 (permalink)  
Old April 10th, 2004, 09:15 AM
Imar's Avatar
Imar Imar is offline
Wrox Author
Points: 72,038, Level: 100
Points: 72,038, Level: 100 Points: 72,038, Level: 100 Points: 72,038, Level: 100
Activity: 100%
Activity: 100% Activity: 100% Activity: 100%
Join Date: Jun 2003
Location: Utrecht, Netherlands.
Posts: 17,080
Thanks: 80
Thanked 1,587 Times in 1,563 Posts

Hi Ron,

The logs you posted actually consists of two parts: a header and the actual page requests. The header (see below) can appear multiple times in the same log file, and is written every time the IIS process starts.

#Software: Microsoft Internet Information Services 5.0
#Version: 1.0
#Date: 2004-04-08 13:11:28
#Fields: time c-ip cs-method cs-uri-stem sc-status

So, when you boot and request the first page in your site, restart IIS manually or when the IIS process is recycled, you'll see this header appear in your log file. If you see many headers for the same date, you're probably using process recycling. You can also see the date and time the process was started. If the date and time more or less matches the date and time your session values are lost, you probably found the cause of the problem. In Windows Server 2003, you'll find this setting on the Properties for the Application Pool your application is using. Can't remember where exactly it is locate on Windows 2000.

The other part of the log files contains the actual hits. You'll see the time and the client's IP address (c-ip), the method (Post, Get, etc), the URL of the page (cs-uri-stem) and the status. Look in the IIS help for a full description of all error codes and info about the logging and other stuff you can log.

Storing "the session variables in cookies instead of inproc" isn't really the way things work. A cookie is used to track the ID of the sessions, so when you visit another page in your application, IIS is able to hook up your request to the existing session object that holds the session values. This object always needs to be saved on the server. How this session object is stored is important. InProc means it's saved within the IIS process. StateServer uses a different stateserver, a process (a Windows Service) that can run on the same or another computer and that does not go down with IIS. The third alternative is to use a database, as Peter suggested.

I think you're best off using the StateServer setting as it will protect your session variables without the need to set up the state server functionality in SQL Server.

The IIS Process Recycling on Win2000 is an add-on. See here for more details:
That also makes it less likely you have it enabled, though....

Hope this helps,


Imar Spaanjaars
Everyone is unique, except for me.
While typing this post, I was listening to: Faces And Names by Lou Reed & John Cale (Track 7 from the album: Songs For Drella)
Reply With Quote