Короче говоря, ASP.NET не может прочитать зашифрованную строку соединения для состояния сеанса, если строка соединения достаточно длинная.
Вот подробности:
Мы одновременно обновляем Windows Server2008 и ASP.NET 4 и не может настроить нашу среду разработки.Мы сохраняем наше состояние сеанса в SQL Server и имеем соответствующую конфигурацию в web.config
<sessionState mode="SQLServer" sqlConnectionString="registry:HKLM\Software\SomeAppName\SessionState\ASPNET_SETREG,sqlConnectionString" cookieless="false" timeout="640" allowCustomSqlDatabase="true" />
. Мы создали запись в реестре с
aspnet_setreg.exe -k:Software\SomeAppName\SessionState -c:"data source=SomeSqlServer\INST3;initial Catalog=AspStateDb;user id=some-user;password=some-password"
и скопировали ее из WOW6432NODE в нужное место и применилисоответствующие разрешения (дал полный доступ к NETWORK_SERVICES всему поддереву HKLM \ Software \ SomeAppName).
И вот тут начинаются странные вещи.Когда мы пытаемся открыть приложение в браузере, мы получаем «Ошибка чтения информации о конфигурации из реестра».ошибка, указывающая на конфигурацию sesssionState.Вот подробности из 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 impersonating: 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)
Странно то, что эта ошибка зависит от длины содержимого строки подключения sql.Мы использовали SysInternals ProcMon и видим, что w3wp.exe действительно успешно читает раздел реестра.Единственное различие между «работающим» и «не работающим», по-видимому, заключается в том, что в рабочем случае w3wp.exe считывает его за одну попытку, в то время как при «неработающей» первая попытка завершается неудачно с переполнением буфера (может быть совершенно не связано, но выглядит подозрительно).
Наше текущее решение столь же странно, как и поведение, которое мы видим: мы явно добавили запись в файл hosts, чтобы сделать более короткий псевдоним для SomeSqlServer просто как «s» (один символ).Это, кажется, уменьшает строку соединения достаточно, чтобы заставить это работать.Однако непонятно, что происходит и почему это помогает вообще.
Наша «неработающая» строка соединения имеет длину около 90 символов.«Рабочий» - меньше 80. Мы не тратили время на поиск точного края.
Мы также пытались сократить строку подключения в реестре (устанавливается с помощью aspnet_setreg.exe) другими способами:
- Мы временно создали пользователя SQL Server «a» с паролем «a» и используем его в строке подключения.Похоже, что это также «решает» проблему.
- Мы ввели неверный пароль длиной 1 символ для существующего пользователя в строку подключения, и ошибка, как ожидается, изменится на невозможность входа в SQL Server.
- МыЕсли указать неверную (но короткую) строку подключения, то ошибка изменилась на что-то из-за неправильного формата строки.
Каждое имеющееся у нас свидетельство указывает на то, что что-то не так с относительно длинными зашифрованными строками подключения в реестре, но этоне понятно что и почему.И почему у нас нет ничего подобного в нашей предыдущей среде (Windows Server 2003 + ASP.NET 2.0)?На самом деле, трудно поверить в такую странную ошибку, но у нас пока нет других идей.
Кто-нибудь видел что-то подобное раньше?У вас есть какие-нибудь предложения?Трудно погуглить эту ошибку, потому что есть журнал подобных жалоб, которые исправляются при наличии соответствующих разрешений в реестре, но мы совершенно уверены, что это не наш случай.