We've started to see instances on our Intranet server where for any page the server just responds with the error page 'HTTP/1.1 New Session Failed'. It seems we can fix it by running IISRESET but this feels like we're only treating the symptom.

The server is a virtualised server running IIS6 on Windows Server 2003 with 0.5Gb of RAM. Our Intranet is written in ASP, but we also have ASP.NET 2.0 applications running on the web site. The site is set up for Anonymous and Integrated Authentication.

What causes IIS to get into this error state? Could the server be saturated with requests i.e. we need to scale out and move some applications onto another server?

I've seen KB210842 but I'm not sure it applies as that is applicable to IIS 4

  • One of our guys had a look at the server last night, he's come back with some things need to be done on it - disable screen saver, install Windows updates, install VMWare tools. Which I can see all need doing but I think it will still need more memory. May 6 '09 at 14:16
  • 2
    It will definitely still need more memory. The screen saver doesn't matter (3D screen savers can eat up a little bit of RAM, but the default Win2k3 one won't make a difference). Windows Updates are necessary of course, but will not solve this problem. VMWare tools will streamline your interactions with the server, but will not improve your performance. Upgrading it to 2GB of RAM will make all the difference.
    – sh-beta
    May 6 '09 at 20:05

How much memory is available when you get that error? If you've saturated all memory, new sessions will fail.

  • Available virtual memory is 16Mb, physical is 17Mb. May 5 '09 at 14:53
  • That's way too little available memory. You mention this is a virtualized server, give it more memory!
    – WaldenL
    May 5 '09 at 16:46

Your event logs probably have more information. Check Application logs and System logs for errors.

512MB of RAM is not enough for Windows 2003 + IIS 6 with any respectable load - especially with ASP .NET 2.0. Upgrading to 1GB will make a big difference.

  • I've spotted some errors in the Application log from COM+ that seem to correspond with the approximate time of the IIS errors and talk about the server running very low on available memory. I've requested the server gets upgraded to 2Gb of memory minimum. May 5 '09 at 16:37

I want to add a few bits of info here. The problem has only one direct cause - not enough memory new session allocation. The real question is what consumes the memory and obviously the answer is different in each different situation. Let me say a few words about my setup first:

I am hosting on Virtuozzo based VPS-es and there you can see the problem more clearly. What is the difference - on VMWare you have something resembling a real machine - with swap file and ram, they might not correspond exactly to the real thing, but effectively a VMWare (and any hardware virtualization based solution) can be treated as a real machine. With Virtuozzo you get only RAM - part of it would be in the page file, but from inside the VPS you can't really see the difference. So, I am using VPS-es with as little memory as 286MB and that is all the memory I can use, when you use VMWare with memory set to 286 you may have also some additional swap space thus your usable RAM would be more (how much depends on the paging file size of course).

On 286 MB machine I can host some 15-20 applications with fair amount of visitors. I am using my own framework and components - including own database engine. I am sure no memory leaks occur (after years and years of testing), but 286MB of memory in total is very thin ice. You would get the "new session failed" from time to time - the question is how to avoid being stuck with it until restart (of IIS or the machine). The answer is adjusting the memory limits of the COM+ application and may be some other recycling options. You should make sure that the limits are such that the worker process will be recycled when the things get ugly and you should keep in your head the total amount of memory used by all the COM+ applications you are using because if the total amount of memory limits is greater than the usable memory you can get in a situation where none of the worker processes is over the limit but all together are occupying all the available memory and none would recycle to free some precious megabytes.

Another thing to check is the ASP caching options - how much files are cached in memory, how many script engines are cached (this happens in memory also). The defaults are quite big and the effect resembles memory leaking - especially if you have many ASP files and many sites (the caching is configured on a global level, but is done in the worker processes).

So, by fine tuning the COM+ applications and the cache options you can get your server running if not absolutely smoothly then at least make sure it will automatically recover with possible only a few requests per day at most (from let say hundred thousand) returning New session failed. If you keep the number of COM+ applications low (2-3 at most) you can keep the track and choose appropriate memory limits, perhaps set up time interval recycling for the applications that are not sensitive to session losses etc.

There is one other thing to consider .NET applications on the same server. Without attention they can kill everything else and grab all the server resources. The problem is the garbage collecting - the ASP.NET (and any .NET) applications will not release their memory because some ASP classic or PHP application needs it and will keep the memory occupied even if they are not using it - eventually they will free it, but they may keep it for hours - just so. The solutions are - avoid mixing .NET and non-.NET apps on the same server, if you cannot avoid it put the .NET apps in separate COM+ pools and set strict memory limits and make them as low as possible.

Well, I hope this is helpful. I have a lot of experience managing servers with little memory available - it is not very difficult, but one need to pay attention and not hope the problem will go away with a patch or another magical solution.


Are you running session-state in IIS, or in the out-of-proc provider. Moving session state to the provider will allow you to use the memory from the session-state service instead of the IIS process. Also, session-state will survive IIS and app domain restarts. I'd also note that 512Meg is on the small side.

  • I'd have to go through the codebase and check but I don't think anything is using session state. I suspect memory may be the main culprit here. May 5 '09 at 14:54

It seems IIS6 doesn't have enough memory to allocate to the session. If this is happening too often, you might need to set a memory recycle limit on your application pool. That way it will not "eat" all your available resources. Keep in mind that recycling the memory will cause the losing of the session.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.