Session State Lost Between Postbacks

I was troubleshooting a bug for the past couple days in which all session data was being lost upon postback. At first, it appeared that certain objects were being reset or nulled upon specific events being raised. Then, some preusal of my debug logs showed that the User was being reinitialized between every click. My error logs in SQL and log files showed tons of “Object reference not set to an instance of an object” errors, despite the entire methods being encapsulated within Try-Catch blocks. At this point, they seemed like seperate bugs.

The part that bothered me the most about this whole fiasco was that I couldn’t replicate the issue in Dev or Test. Only in Production was this issue occuring - The one customer-facing environment; Great.

Then I increased the frequency and verbosity of the logging output. I saw that I was putting valid objects into session, and that they remained there for the duration of the local method. However, when the method exited and its parent method resumed, it couldn’t access those session values. Public variables were being nulled in the same manner. It quickly became evident at this point that all my similar issues were actually one big issue.

So I tried to code around it with some clever tomfoolery - The same basic things every web developer tries in this situation - Basically passing data among publics, session, and hidden fields. Only the hidden fields would retain the value, but they’re only good for text. I can’t store an instantiation of a custom class within a textbox!

After two days of hair-pulling, J suggested I reinstall IIS and the .NET Framework. These were both recent installs on a brand-new server, so I had been leaning away from that eventuality. Alas, I had run out of options.

I reinstalled IIS on the production server. Suddenly the server refused to serve the site at all. Apparently, the page cannot be displayed. Quickly, I leapt into the IIS configuration to discern what had transpired. My SSL certificate was in place, my files were there, and my ISAPI filters were correctly installed and prioritized. In fact, all of the website and application pool settings were correct. Then I had a look at the Web Service Extensions tree node.

When compared to the other environments, I noticed I was missing two extensions: ASP.NET 2.0 and Netegrity (Which we use for authentication). Reinstalling the .NET Framework 2.0, 2.0 SP1, and 3.5 didn’t replace the filter; Fortunately, I was able to locate it with minimal time delay. It was supposed to map to %WINDIR%\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll.

Alas, Netegrity was still without extension pointer. Adding the pointer in the same manner and cycling the app pool had no effect, despite the fact that the executable was running. So I looked through the logs and config files. Finally, I discovered the Agent Configuration Wizard, which allowed me to re-enable the agent. After I cycled IIS on the box (to reset the ISAPI filter), the site was finally running again.

My session state was working.