Found the problem. Has to do with technical details of how IIS (Internet Information Services, the web server software this site runs on.) works.

A few days ago, I changed MessageBase to run in it's own "Application Pool", instead of the default application pool that everything else on the server runs on. This makes it so if MessageBase crashes, it won't take down the other apps on the server, and vice versa.

That was all well and good. However, while setting up the new Application Pool, I noticed a cool little setting called "Maximum number of worker processes" which was set to 1. I figured since the server has two processors in it, it would make sense to set it to use 2 worker processes, so it could spread the load between the two processors. Well, it turned out that while that was a great idea, I should have read the instructions. (Go figure!!)

When you set the number of worker processes to more than one, this turns the basic application pool into what's strangely called a "Web Garden". This is a great thing for two reasons:

• Robust processing of requests: When a worker process in an application pool is tied up (for example, when a script engine stops responding), other worker processes can accept and process requests for the application pool.
• Reduced contention for resources: When a Web garden reaches a steady state, each new TCP/IP connection is assigned, according to a round-robin scheme, to a worker process in the Web garden. This has the effect of smoothing out workloads and reducing contention for resources that are bound to a worker process.

However, there's another step I didn't know I had to do. When running with more than one process, the session information is NOT shared between the two processes. One of the worker processes will store your information when you send a request to the web server. As long as that worker process handles all your requests, everything works just fine. However, as soon as the other worker process picks up one of your requests, problems occur as the second worker process has no information about you or what you've done previously, and it doesn't see your "Session ID", so throws you to the main page since that's what I've got it set to do in case of a problem, such as requesting a message that doesn't exist.

There's a pretty easy way to set up the IIS State Service to store the session info so any of the worker processes can find your session information. However, since I store some non-primitive data in session, it'd require going through the code and making a few tweaks, so I'm going to leave that for a future day. I set the number of worker processes back to 1 for the meantime and everything is good.

If you're reading this because you are having a similar problem with your session state disappearing for no reason, there's some good info about doing this the right way in an article called IIS Dropping Sessions.

Sorry about causing the interruption here on MessageBase! (As an aside, I've increased the session timeout for (only) the Post a Message page, I'd had some complaints about errors when posting a message. (20 minutes just isn't enough, it's bitten me a few times as well. Now you have 45 minutes.)