Hello all! I hope that you can help me out.

Our Web site went down this morning and we are in dire need of guidance. My colleague and I are simple Web developers. We have designed, developed and maintain a .NET-based Web site complete with master pages, server controls and content pages. Three times this past year our Web site has went down. The Web server that holds all of our files and folders are located and maintained by a totally different crew at our college's District offices.

We know that this is a problem related to .NET since the other colleges in our district who use predominantly HTML have no such problems.

Each time this happens, no one  in the network department knows what happened and we're left to sort through things and try to "paddle" our way through it. They say that no one made updates, turned anything off, etc. Can you please tell us what may be the problem and how to fix it?

Hi,

It sounds pretty logical that a static HTML website is going to be more reliable than an ASP .NET based one, simply because the dynamic site is using far more resources when pages are accessed.

If an ASP .NET website encounters a problem, though, it has the capability to restart, or "recycle" itself. To be honest, almost all web applications I have ever seen need to be recycled periodically, because they hold onto sessions for too long or just plain fragment the memory space too badly. The IIS 6 Administrator snap-in has recycling settings under the "application pools" container that can be used to configure what will trigger recycling, whether it's high memory usage, a certain time, or after a certain number of requests.

If there is a serious problem that causes the application pool to recycle repeatedly in rapid succession, then "Rapid Fail Protection" may have kicked in and permanently disabled the website. This is configured on the Health tab of the application pool properties page.

Most times, there is an adequate explanation in the System log that will say why the IIS process had failed. It may be something easily fixed administratively, for instance by adding more memory to the server or reconfiguring some services.

In serious crashes where the website's code may be to blame, it may be useful to try Microsoft's DebugDiag tool to figure out what had happened.

I hope this helps!