Ошибочная ошибка Viewstate в приложении .NET

Question

Я, кажется, время от времени получаю "недопустимое состояние просмотра" в средстве просмотра событий для моего приложения ASP.NET .

Большинство из них (95%), похоже, ссылаются на ScriptResource.axd (приложение использует библиотеку ASP.NET AJAX ). Я не могу удалить библиотеку Ajax , так как Ajax используется везде ..

Как я могу уменьшить эти ошибки? Я получаю ~ 100-200 ошибок в день, и я не знаю, как их исправить! Они приходят из разных браузеров, разных IP-адресов и географических местоположений.

Мне трудно воспроизвести проблему, потому что она едва случилась со мной, она случалась со мной только 3-4 раза.

Ошибка:

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

Exception information: 
    Exception type: HttpException 
    Exception message: Invalid viewstate. 

Request information: 
    Request URL: http://domainnamehere/ScriptResource.axd?d=W1R6x9VzZ2C9SKnIkOmX9VRLhSjJ3nOF1GSQvPwKS3html 
    Request path: /ScriptResource.axd 
    User host address: 124.177.170.75 
    User:  
    Is authenticated: False 
    Authentication Type:  
    Thread account name: NT AUTHORITY\NETWORK SERVICE 

Thread information: 
    Thread ID: 1 
    Thread account name: NT AUTHORITY\NETWORK SERVICE 
    Is impersonating: False 
    Stack trace:    at System.Web.UI.Page.DecryptStringWithIV(String s, IVType ivType)
   at System.Web.UI.Page.DecryptString(String s)
   at System.Web.Handlers.ScriptResourceHandler.DecryptParameter(NameValueCollection queryString)
   at System.Web.Handlers.ScriptResourceHandler.ProcessRequestInternal(HttpResponse response, NameValueCollection queryString, VirtualFileReader fileReader)
   at System.Web.Handlers.ScriptResourceHandler.ProcessRequest(HttpContext context)
   at System.Web.Handlers.ScriptResourceHandler.System.Web.IHttpHandler.ProcessRequest(HttpContext context)
   at System.Web.HttpApplication.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


Custom event details: 

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Я также время от времени получаю эту ошибку в моем .NET-коде, который происходит одновременно и может быть связан:

Exception raised in GLOBAL.ASAX.Application_Error(): 'Padding is invalid and cannot be removed.' at System.Security.Cryptography.RijndaelManagedTransform.DecryptData(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount, Byte[]& outputBuffer, Int32 outputOffset, PaddingMode paddingMode, Boolean fLast)
   at System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock(Byte[] inputBuffer, Int32 inputOffset, Int32 inputCount)
   at System.Security.Cryptography.CryptoStream.FlushFinalBlock()
   at System.Web.Configuration.MachineKeySection.EncryptOrDecryptData(Boolean fEncrypt, Byte[] buf, Byte[] modifier, Int32 start, Int32 length, IVType ivType, Boolean useValidationSymAlgo)
   at System.Web.UI.ObjectStateFormatter.Deserialize(String inputString)

Answer 1

Похоже, это та же проблема IE8, с которой сталкивались многие люди. Кажется, что происходит то, что IE8 (как в режиме рендеринга IE8, так и в режиме совместимости IE7) теряет 4096 байт из середины HTML-документа, и эти отсутствующие данные вызывают это исключение (вы обычно видите это в вызове ScriptResource или WebResource) .

Вот отчет об ошибке Microsoft по этой проблеме: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997

Также есть много сообщений на форуме, блоге и т. Д. По этому вопросу:

• Созданы неверные параметры Webresource.axd
• IE 8 сбрасывает страницы памяти?
• http://forums.asp.net/t/1373410.aspx?PageIndex=1
• http://forums.asp.net/p/1409964/3085329.aspx

---

Microsoft ответила на эту проблему:

Примечание - это ошибка в Internet Explorer 8. Команда Internet Explorer занималась этой проблемой.

Влияние : Пока мы считаем, что проблема не влияет на работу конечного пользователя с веб-приложением; единственный отрицательный эффект - ложные / неправильно сформированные запросы, отправленные механизмом спекулятивной загрузки JavaScript. Когда скрипт действительно нужен анализатору, он будет правильно загружен и использован в это время.

Обстоятельства : ложный запрос появляется только в определенных временных ситуациях, только когда в документе появляется тег META HTTP-EQUIV, содержащий Content-Type с директивой CHARSET, и только когда URL SRC JavaScript занимает 4096-й байт тела ответа HTTP.

Обходной путь: Следовательно, в настоящее время мы считаем, что эту проблему можно устранить, объявив CHARSET страницы, используя заголовок HTTP Content-Type, а не указав его на странице.

Итак, вместо того, чтобы ставить

<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">

Вместо этого отправьте в свой заголовок тег следующий HTTP-заголовок ответа:

Content-Type: text/html; charset=utf-8

Обратите внимание, что спецификация кодировки в заголовке HTTP приводит к повышению производительности во всех браузерах, поскольку синтаксическим анализаторам браузера не нужно перезапускать синтаксический анализ с самого начала при обнаружении объявления набора символов. Кроме того, использование заголовка HTTP помогает смягчить некоторые векторы атак XSS.

ПРИМЕЧАНИЕ. Были сообщения, что эта проблема все еще возникает, когда META HTTP-EQUIV нет на странице. Мы обновим этот комментарий, когда у нас будет больше расследований.

Опубликовано Microsoft 30.06.2009 в 12:25.

Edit: Я все еще иногда вижу это исключение, но эта ошибка, как сообщается, исправлена: http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

Answer 2

Я полагаю, вы используете ASP.NET AJAX. Я с той же проблемой. Спорадически я бы нашел это исключение в моем журнале событий, и запрошенный путь ВСЕГДА ScriptResource.axd.

Использование фиксированных ключей validationKey и decryptionKey в machineKey не решило проблему для меня.

Основываясь на том, что мне удалось собрать, я склонен полагать, что эта ошибка не имеет никакого отношения к ViewState; Моя теория состоит в том, что по каким-то причинам некоторые UA как-то портят параметр "d" в ScriptResource.axd. Эта проблема легко решается путем ручного запроса неверного пути. Это дает исключение «Invalid ViewState», хотя ViewState здесь даже не применяется.

Копаясь в моих журналах, я нашел, например:

Этот запрос обслуживается в порядке (200): /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NRCY1n0_DNg1nE6-DDbsD6r4EiuwoeDzp9mjDDfBNLb1k1&t=41df03cc

Этот немного другой запрос также выполняется OK (200): /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NR5ijsxQts4AfbJdACRwmQ8sHt6UAzui3spEnooPneTz01&t=41df03cc

Этот запрос не выполняется с ответом 500 и исключением Invalid ViewState: /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_3products$ctl00$AddToCart1$id

Если присмотреться, первые несколько символов во всех трех запросах одинаковы, но последние несколько символов последнего запроса (выделены жирным шрифтом) явно представляют собой контрольный идентификатор "products $ ctl00 $ AddToCart1 $ id" (у меня есть контролирует названные продукты и AddToCart). Я не знаю, как этот идентификатор попал туда, но в моем случае именно это вызывает все эти недопустимые исключения ViewState.

Я не уверен, является ли это тем же случаем, что и OP, но я замечаю, что URL-адрес запроса Мартина оканчивается на «html», что является небольшим совпадением для параметра, который должен быть ключом. ..

У меня уже болит голова из-за этой проблемы. И до сих пор самый проницательный пост, с которым я сталкивался, это http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

Есть идеи?

Answer 3

Проблемы с Viewstate раздражают и расстраивают - я заметил, что несколько человек говорили о наличии проблем с Viewstate в этой теме. Итак, вот несколько предложений, которые вы можете посмотреть по порядку.

1. Я бы повторил то, что сказал Фредди Риос в теме уже. Удостовериться что вы жестко закодировали машину ключ. Это решит огромное большинство из этих вопросов. важная вещь о Ссылка ScriptResource такова, что должен иметь параметр d и т параметр в строке запроса. Если оно что-то еще не так!

2. Не позволяйте пользователю выполнять обратную передачу до Вы сделали. Вы могли бы, вероятно, сделать это с JavaScript и немного CSS. По памяти я думаю, что есть способ сделать это с метатегом, но это может быть только IE.

3. Я бы посмотрел на смывает ответ рано. Я бы подумал после менеджер сценариев будет лучше. Но вам может понадобиться экспериментировать бит.

4. Если ваше состояние выглядит раздутым, включить сжатие GZip в IIS.

5. Если ваше представление стало действительно раздутый, и вы не можете получить GZip сжатие включено / или имеет нежелательный побочный эффект. Тогда ты можешь сжать и распаковать ViewState. http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx

6. Если это все еще оставляет вас с раздутый вид, вы можете посмотреть на хранение состояния на месте. http://blog.arctus.co.uk/articles/2007/04/23/advanced-asp-net-storing-viewstate-in-a-database/ хорошая отправная точка.

Answer 4

Я думаю, вы должны использовать на странице aspx:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

Это решит мою проблему

Answer 5

У меня также есть эта проблема, и я перепробовал все, что упоминалось во всех блогах, которые я нашел (фиксированный ключ компьютера, размер представления и т. Д.). 99% времени ошибка регистрируется при запросах к ScriptResource.axd. Я использую .net 3.5 SP1, на сервере Win 2003. Приложение размещено на двух параллельных идентичных серверах, баланс 50/50. Каждый сервер имеет один и тот же машинный ключ.

Обычно эта ошибка меня не особо волнует, однако в течение 3-х месяцев тенденция к возникновению значительно возросла.

Кто-нибудь думает, что эта ошибка связана с тем, что Viewstate неправильно UrlEncoded / HtmlEncoded или UrlDecoded. Возможно, в представлении есть подмножество символов, которое некоторые браузеры заменяют некоторым закодированным значением. Я не уверен, имеет ли это смысл ...

Answer 6

Я видел подобные проблемы, когда Viewstate слишком велик. Я видел, как это произошло из-за проблемы, которую описывает Фредди.

Мне вообще не нравится идея использовать Viewstate. Вы можете вообще отключить Viewstate?

Answer 7

Используйте фиксированный машинный ключ (даже при работе на одном сервере).

Проблема возникает при использовании автоконфигурации для ключа машины, вы получаете новую каждый раз при перезапуске домена приложения. Это влияет на проверку состояния представления, расшифровку строки запроса динамических ресурсов и проверку подлинности [вставьте другие варианты использования ключа машины].

Answer 8

Проблема, похоже, в загрузчике IE8.

Похоже, что он влияет только на IE8 в довольно неясных обстоятельствах. Одна из причин, по которой он может остаться незамеченным, заключается в том, что блок данных 4k, добавляемый к URL-адресу, часто отбрасывается сервером. Одна из вещей, которая, кажется, делает это более вероятным, - медленное сетевое соединение. Кто-то из перечисленных ниже источников отметил, что у него была проблема только с его клиентами в Новой Зеландии.

Множество людей объясняют две отдельные проблемы, одна из которых описана в приведенном выше вопросе (неправильные URL-адреса отправлены на сервер):

http://connect.microsoft.com/VisualStudio/feedback/details/434997/invalid-webresource-axd-parameters-being-generated

Статья, объясняющая, что загрузчик lookahead исправлен:

http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

KB980182 - Накопительное обновление, в котором устранена проблема:

http://support.microsoft.com/kb/980182

ПРИМЕЧАНИЕ: Поскольку скрипт автоматически перезагружается, если он не может быть получен загрузчиком lookahead, должна быть возможность вернуться к старому режиму проверки, в котором файлы .axd не проверил на валидность и убрал симптомы проблемы:

<httpRuntime requestValidationMode="2.0" />

Answer 9

Я только что сузил эту проблему для пользователя с антивирусом Trend Micro, и ошибки только начали появляться после того, как он обновил свое программное обеспечение Trend Micro 21.05.2009. До этой даты ошибок нет.

Answer 10

Вы используете неанглийскую операционную систему?

По некоторым причинам имя учетной записи «NT Authority \ Network Service» было локализовано на других языках.
К сожалению, многие программы имеют имя учетной записи, жестко запрограммированное на английское имя, и не будут обнаруживать сетевую службу при работе на сторонних версиях Windows, что приводит к всевозможным шуток в журнале событий.