Changing machineKey settings in Web.config causes bad behaviour?

Published to Blog on 11 Dec 2006

Friday night I tried to update the machineKey section of a web.config file of a site so that it could share logins with another couple of sites. I have done this before a couple of times with those sites.

The site currently has the machine keys specified in the web.config so I assumed it would be a pretty simple procedure to swap it out with the new one shared by the other two sites.

However, after saving the web.config changes the site basically stopped performing. I could get a page to come up about once in every 30 or so attempts, the app pool shut down a couple of times and the site basically just stopped working. I checked the event log and the errors that it showed (from memory) were basic ASP.NET 2.0 framework exceptions - no details and nothing that provided me any further direction. Note: If I try this again I and get the same results I will record some of the errors.

I know that I should expect ViewState issues because of the machineKey change, but I didn’t expect a total “crash” of the site. I let the site run for a while hoping that it would straighten itself out, but after 30 minutes I gave up. Upon changing the machineKey settings back the site began working great again after a few seconds to recycle the app pool and fill up cache (the site makes use of a LOT of caching).

I double checked to make sure that the only thing that I changed was the encryption and decryption keys and that was the case. I attempted the same procedure a couple more times with the same results.

I spent a couple hours that night searching Google and MSDN, but really saw nothing similar to what I was experiencing. I’ve done the same again today with about the same luck.

I stopped and restarted the site and the app pool a couple of times but that did not help. The one thing that I did not do is stop and restart the www service. I can give that a try. I will also try deleting my cookies, but I think I did that before, too.

Finally, I tried the same changes on a dev version of the site on the same server and it responded fine to the change.

Anyone run into something like this before? Have any tips or suggestions?

asp-net

Dan Hounshell
Web geek, nerd, amateur maker. Likes: apis, node, motorcycles, sports, chickens, watches, food, Nashville, Savannah, Cincinnati and family.
Dan Hounshell on Twitter

On 9 Jan 2007 "sonnyMal"" said:
Dan, this might be obvious, but if your using cookie-less authentication and profile, the profiler provider will no longer have knowledge of existing profiles as the cookie key generated is based on the machine key. Questions if your working in a web farm, are all servers using same machine key. Check trust level of the application, this might also stop changes to machine key. Not sure if i helped out, but i tryed ) Cheers SonnyM
On 9 Jan 2007 """ said:
Thanks, SonnyM. We're using cookies, not going cookie-less. Two separate sites that share logins are on a two-server cluster. These both have the same machine keys and shared login works fine. I am trying to get one additional site that is on a separate server to share logins with the other two. More updates I have tried this a few more times along with some other troubleshooting efforts. I created a copy of the site with the new machine key and with a new subdomain pointing to it and it worked fine. We decided that it might be an IIS metabase corruption issue with the current site, so I setup another copy of the site using the new machine key, turned off the old one, turned on the new one and the same thing happened as before. I can get a page or two to come up when the app pool is restarted, but after that the site just stops responding. A ton of exceptions are being recorded in the event log, though - invalid viewstate and a lot of .net framework kernel32 exceptions, but they don't really provide any other info. My thoughts are that this site gets so much traffic that when I try to change the machine key so many viewstate exceptions are created that the site just slows to a crawl. We may have to just shut the site down for a few hours to be able to make this change. I'll update here when more information is available.