Weird "Error reading configuration information from the registry." for ASP.NET sessionState sqlConnectionString (not permissions)

In short it seems that ASP.NET fails to read encrypted connection string for session state if connection string is long enough.

Here are details:

We are upgrading simultaneously to Windows Server 2008 and ASP.NET 4 and can't set up our dev environment. We store our session state in SQL Server and have corresponding configuration in web.config

<sessionState mode="SQLServer" sqlConnectionString="registry:HKLM\Software\SomeAppName\SessionState\ASPNET_SETREG,sqlConnectionString" cookieless="false" timeout="640" allowCustomSqlDatabase="true" />

We created entry in registry with

aspnet_setreg.exe -k:Software\SomeAppName\SessionState -c:"data source=SomeSqlServer\INST3;initial Catalog=AspStateDb;user id=some-user;password=some-password"

and copied it from WOW6432NODE to proper place and applied proper permissions (gave Full Control to NETWORK_SERVICES to whole subtree HKLM\Software\SomeAppName).

And this is where weird things starts. When we try to open the application in browser we get "Error reading configuration information from the registry." error pointing to sesssionState configuration. Here are details from the EventViewer

Event code: 3008 
Event message: A configuration error has occurred. 
Event time: 9/8/2011 7:32:02 AM 
Event time (UTC): 9/8/2011 2:32:02 PM 
Event ID: 6e68be241c3d4105a0dec4de7b3724d0 
Event sequence: 2 
Event occurrence: 1 
Event detail code: 0 

Application information: 
    Application domain: /LM/W3SVC/blah-blah-blah
    Trust level: Full 
    Application Virtual Path: /SomeAppName 
    Application Path: C:\inetpub\wwwroot\SomeAppName
    Machine name: SomeWebServer 

Process information: 
    Process ID: 4044 
    Process name: w3wp.exe 
    Account name: NT AUTHORITY\NETWORK SERVICE 

Exception information: 
    Exception type: ConfigurationErrorsException 
    Exception message: Error reading configuration information from the registry. (C:\inetpub\wwwroot\SomeAppName\web.config line 89) 

Request information: 
    Request URL: http://SomeWebServer/SomeAppName/default.aspx 
    Request path: /SomeAppName/default.aspx 
    User host address: 10.X.X.X
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: NT AUTHORITY\NETWORK SERVICE 

Thread information: 
    Thread ID: 3 
    Thread account name: NT AUTHORITY\NETWORK SERVICE 
    Is impersona开发者_StackOverflow中文版ting: False 
    Stack trace:    at System.Web.Configuration.ConfigsHelper.GetRegistryStringAttribute(String& val, ConfigurationElement config, String propName)
   at System.Web.SessionState.SqlSessionStateStore.OneTimeInit()
   at System.Web.SessionState.SqlSessionStateStore.Initialize(String name, NameValueCollection config)
   at System.Web.SessionState.SqlSessionStateStore.Initialize(String name, NameValueCollection config, IPartitionResolver partitionResolver)
   at System.Web.SessionState.SessionStateModule.InitModuleFromConfig(HttpApplication app, SessionStateSection config)
   at System.Web.SessionState.SessionStateModule.Init(HttpApplication app)
   at System.Web.HttpApplication.InitModulesCommon()
   at System.Web.HttpApplication.InitInternal(HttpContext context, HttpApplicationState state, MethodInfo[] handlers)
   at System.Web.HttpApplicationFactory.GetNormalApplicationInstance(HttpContext context)
   at System.Web.HttpApplicationFactory.GetApplicationInstance(HttpContext context)
   at System.Web.HttpRuntime.ProcessRequestInternal(HttpWorkerRequest wr)

The weird thing is that this error seems to be dependent on the length of the sql connection string content. We used SysInternals ProcMon and see that w3wp.exe actually does successfully read the registry key. The only difference between "working" and "not working" seems to be that in working case w3wp.exe reads it in one attempt while in "not working" first attempt fails with buffer overflow (might be totally unrelated but looks suspicious).

Our current solution is as weird as behavior we see: we explicitly added entry to the hosts file to make shorter alias for the "SomeSqlServer" as just "s" (one character). This seems to reduce connection string enough to make it work. However it is not clear what happens and why this helps at all.

Our "not-working" connection string is about 90 characters long. The "working" one is less than 80. We didn't spend time to find exact edge.

We also tried to shorten connection string in the registry (set with aspnet_setreg.exe) in other ways:

• We temporary created a SQL Server user "a" with password "a" and use him in connection string. This also seems to "fix" the issue.
• We put wrong 1 character-long password for existing user into the connection string and error expectedly changed to failure to log into SQL Server.
• We put plainly wrong (but short) connection string and error changed to something about bad string format.

Every evidence we have now points us that there is something wrong with relatively long encrypted connection strings in registry but it is not clear what and why. And why we don't have anything like this in our previous environment (Windows Server 2003 + ASP.NET 2.0)? Actually it is quite hard to believe in such a strange bug but we have no other ideas for now.

Has anybody seen anything like this before? Do you have any suggestions? It is hard to google this error because there are a log of similar complains that are fixed by given proper permissions in registry but we are quite sure that this is not our case.

It is not clear what was this. We can't reproduce it anymore. The best explanation we have for now is that we somehow managed to mess up with permissions.