Problema errático de Viewstate no válido en una aplicación .NET

Question

Parece que estoy obteniendo un "estado de vista no válido" de vez en cuando en el visor de eventos para mi aplicación ASP.NET.

La mayoría de ellos (95%) parecen estar haciendo referencia a ScriptResource.axd (la aplicación utiliza la biblioteca ASP.NET AJAX). No hay forma de que pueda eliminar la biblioteca Ajax ya que Ajax se usa en todas partes.

¿Cómo puedo reducir estos errores? Recibo ~ 100-200 errores al día y no tengo ni idea de cómo solucionarlos. Vienen de diferentes navegadores, diferentes direcciones IP y ubicaciones geográficas.

Es difícil para mí reproducir el problema porque apenas me ha pasado, solo me ha pasado 3-4 veces de la nada.

error:

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. 

También consigo este error de vez en cuando en mi código .NET que se produce al mismo tiempo que podría estar relacionada:

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

Utilice un fijo llave de la máquina (incluso cuando se usa un solo servidor).

El problema se produce al utilizar la configuración automática para la clave de la máquina, se obtiene una nueva cada vez que se recicla el dominio de la aplicación. Esto afecta a la validación de viewstate, a la descifrado de cadenas de consulta de recursos dinámicos y a los tickets de autenticación [inserte otros usos de la clave de máquina].

Answer 2

He visto problemas como este cuando Viewstate es demasiado grande. Lo he visto suceder por el problema que describe Freddy.

Por lo general, no me gusta la idea de usar Viewstate. ¿Puedes desactivar Viewstate por completo?

Answer 3

Supongo que está utilizando ASP.NET AJAX. Estoy teniendo el mismo problema. Esporádicamente encontraría esta excepción en mi registro de eventos, y la ruta solicitada es SIEMPRE ScriptResource.axd.

Usando la validación fijaKey y la clave de descifrado en machineKey no me solucionó el problema.

Según lo que pude reunir, tiendo a creer que este error no tiene nada que ver con el ViewState en absoluto; mi teoría es que, por algún motivo, ciertos AU difuminan de algún modo el parámetro "d" de ScriptResource.axd. El problema es fácilmente replicable al solicitar manualmente la ruta ofensiva. Esto da una excepción de "ViewState inválido", aunque ViewState ni siquiera se aplica aquí.

de excavación a través de los registros de mi, encontré por ejemplo:

Esta solicitud se sirve OK (200): /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NRCY1n0_DNg1nE6-DDbsD6r4EiuwoeDzp9mjDDfBNLb1k1 & t = 41df03cc

Este la solicitud ligeramente diferente también se sirve OK (200): /ScriptResource.axd?d = oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NR5ijsxQts4AfbJdACRwmQ8sHt6UAzui3spEnooPneTz01 & t = 41df03cc

Esta solicitud no con una respuesta 500 y la excepción ViewState no válido: /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_3 productos ctl00 $ $ $ Identificación del AddToCart1

Si mirar de cerca, los primeros caracteres en los tres petición son los mismos, pero los últimos caracteres de la última solicitud (en negrita) claramente es el control de ID "productos $ ctl00 $ AddToCart1 $ id" (tengo controles productos con nombre y addToCart) No sé cómo llegó esta ID, pero en mi caso esto es lo que está causando todas estas excepciones de ViewState no válido.

No estoy seguro de si este es el mismo caso que el OP o no, pero noto que la URL de solicitud de Martin termina en "html", que es una coincidencia para un parámetro que se supone que es una clave ...

ya tengo un dolor de cabeza gracias a este problema. Y hasta ahora, la publicación más perspicaz que encontré es esta http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

¿Alguna idea?

Answer 4

También estoy teniendo este problema, y ​​he intentado todo lo mencionado en todos los blogs que he encontrado (clave de máquina fija, tamaño de viewstate, etc.). El 99% del tiempo se registra el error en las solicitudes a ScriptResource.axd. Estoy usando .net 3.5 SP1, en el servidor Win 2003. La aplicación está alojada en dos servidores paralelos idénticos, balanceados 50/50. Cada servidor tiene la misma clave de máquina.

Normalmente, este error no me preocupa demasiado, sin embargo, durante un período de 3 meses, la tendencia en la ocurrencia ha ido hacia arriba.

¿Alguien cree que este error está relacionado con que Viewstate no está codificado en URL/HtmlEncoded ni está codificado en Url correctamente? Quizás haya un subconjunto de caracteres dentro del viewstate que algunos navegadores están reemplazando con algún valor codificado. No estoy seguro de si que incluso tiene sentido ..

Answer 5

¿Está ejecutando un Sistema de Operación no-Inglés?

Por algunas razones, el nombre de cuenta de "autoridad \ Servicio de red NT" se ha localizado en otros idiomas.
Por desgracia, una gran cantidad de programas que tienen el nombre de cuenta codificado con el nombre de Inglés, y no encontrará el servicio de red cuando se ejecuta en versiones de Windows de extranjeros, lo que lleva a todo tipo de errores enrrollados en el registro de eventos.

Answer 6

Acabo de reducir este problema para un usuario con el antivirus de Trend Micro y los errores recién comenzaron después de que actualizó su software micro de tendencia el 21/05/2009. Sin errores antes de esta fecha.

Answer 7

problemas de estado de vista son molesto y frustrante - Me he dado cuenta de que algunas personas han hablado de tener problemas de estado de vista en este hilo. Entonces, aquí hay algunas sugerencias que puedes ver en orden.

1. me gustaría repetir lo que ha dicho Freddy Ríos en el hilo ya. Asegúrese de que ha codificado la máquina con la clave . Esto resolverá la gran mayoría de estos problemas con . Lo importante acerca del enlace ScriptResource es que debe tener un parámetro d y un parámetro t en la cadena de consulta.¡Si es , no hay otra cosa que esté mal!

2. No dejes que el usuario vuelva a escribir hasta hecho. Probablemente podría hacer esto con javascript y un poco de css. Desde la memoria, creo que hay una forma de hacer esto con una metaetiqueta, pero podría ser solo IE.

3. Lo que quiero ver es descargar la respuesta antes de tiempo. Pensaría que después del el administrador de scripts sería el mejor. Pero es posible que deba experimentar un bit de .

4. Si su viewstate parece hinchado, active la compresión GZip en IIS.

5. Si su estado de vista se ha convertido en realidad hinchado y no se puede conseguir GZip compresión activada/o que tiene un lado no deseado afecta. Luego puede comprimir y descomprimir viewstate. http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx

6. Si aún así te deja con un estado de vista hinchada , usted podría mirar a almacenar el estado de vista a nivel local. http://blog.arctus.co.uk/articles/2007/04/23/advanced-asp-net-storing-viewstate-in-a-database/ es un buen punto de partida.

Answer 8

Este parece ser el mismo problema de IE8 que muchas personas han estado experimentando. Lo que parece suceder es que de alguna manera IE8 (tanto en el modo de renderización IE8 como en el modo de compatibilidad IE7) perderá 4096 bytes fuera del medio del documento HTML y esta falta de datos causa esta excepción (normalmente se ve esto en una llamada ScriptResource o WebResource) .

Aquí es un informe de error Microsoft sobre el tema: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997

También hay un montón de foro, las entradas del blog, etc en este tema:

• Invalid Webresource.axd parameters being generated
• IE 8 dropping memory pages?
• http://forums.asp.net/t/1373410.aspx?PageIndex=1
• http://forums.asp.net/p/1409964/3085329.aspx

---

Microsoft ha respondido a esta cuestión:

Nota es un error en Internet Explorer 8. El equipo de Internet Explorer ha estado investigando este problema.

Impacto: Hasta ahora, creemos que el problema no tiene ningún impacto en la experiencia del usuario final con la aplicación web; el único efecto negativo son las solicitudes espurias/malformadas enviadas por el motor de descarga especulativa de JavaScript. Cuando el analizador realmente necesita el script, se descargará y usará correctamente en ese momento.

circunstancias: La espuria-petición parece ocurrir sólo en ciertas situaciones de tiempo, sólo cuando una etiqueta http-equiv META contiene un tipo de contenido con una directiva CHARSET aparece en el documento, y sólo cuando una URL JavaScript SRC abarca el 4096o byte del cuerpo de respuesta HTTP.

Solución alternativa: Por lo tanto, actualmente creemos que este problema se puede mitigar declarando el CHARSET de la página utilizando el encabezado HTTP Content-Type en lugar de especificarlo dentro de la página.

Así, en lugar de poner

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

En su etiqueta de la cabeza, en cambio, envíe el siguiente encabezado de respuesta HTTP:

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

Tenga en cuenta que la especificación del conjunto de caracteres en los resultados de encabezado HTTP en la mejora rendimiento en todos los navegadores, porque los analizadores del navegador no necesitan reiniciar el análisis desde el principio al encontrar la declaración del juego de caracteres. Además, usar el encabezado HTTP ayuda a mitigar ciertos vectores de ataque XSS.

NOTA: Ha habido informes de que este problema todavía ocurre cuando META HTTP-EQUIV no está en la página. Actualizaremos este comentario cuando tengamos más investigación.

Publicado por Microsoft el 30/06/2009 a las 12:25 p. M.

Editar: todavía veo esta excepción de vez en cuando, pero este error se reporta como fijo: http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

Answer 9

creo, debe utilizar en la página 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"> 

Esta resolver mi problema

Answer 10

El problema parece ser el programa de descarga anticipada en IE8.

Parece que solo afecta a IE8 en un conjunto bastante oscuro de circunstancias. Una de las razones por las que puede pasar desapercibido es que el servidor descarta a menudo un fragmento de 4k adjunto a una URL. Una de las cosas que parece hacer que sea más probable es una conexión de red lenta. Alguien en uno de los recursos a continuación señaló que solo tenía el problema con sus clientes en Nueva Zelanda.

Mucha gente que explican dos problemas separados, uno de los cuales se describen en la pregunta anterior (URL malformadas enviadas al servidor):

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

artículo explicando que el programa de descarga de búsqueda hacia delante es fijo:

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

KB980182 - actualización acumulativa en el cual problema se corrigió:

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

NOTA: Debido a que el script se vuelve a descargar de forma automática si no podría ser recuperado por el programa de descarga de búsqueda hacia delante, debería ser posible cambiar de nuevo al viejo modo de validación en el que los archivos .axd no se verificaron para verificar su validez y eliminar los síntomas del problema:

<httpRuntime requestValidationMode="2.0" />