viewstate scriptresource.axd

viewstate - Error de estado de vista no válido



scriptresource.axd (9)

¿Qué tan grande es el estado de vista? Algunos servidores proxy truncarán un estado de vista grande.

Es fácil abusar de viewstate ya que está activado de forma predeterminada. Si tiene un estado de visualización grande, es probable que desee considerar la desactivación del estado de visualización en los controles que no lo necesitan.

Recibo un error de estado de vista no válido con respecto al ScriptResource.axd. Solo me pregunto si alguno de ustedes podría ayudarme en esto. Error es:

2009-02-24 09:46:30,021 [13] DEBUG ASP.global_asax [(null)] - Request start - URL: /Web/ScriptResource.axd?d=E9hlvtsn8Gr1MyjysW1gFDFYr4CVwstY-sC22tRu5V8d7UyEYz3FhVYGrlhY87n2ihgKh58RrMRhK-Yk2WcQahEaCg_asTInqHK 2009-02-24 09:46:30,021 [13] DEBUG ASP.global_asax [(null)] - Application_AuthenticateRequest started 2009-02-24 09:46:30,021 [13] ERROR ASP.global_asax [(null)] - Unexpected error. User presented with Site Error page. System.Web.HttpException: Invalid viewstate. 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)

Esto sucede en el entorno de producción. No puedo reproducir esto en entornos de prueba ni dev. También a estas páginas solo pueden acceder usuarios autenticados. Sería realmente si pudieras arrojar algo de luz sobre este asunto.


Como se dijo, esto podría suceder si está utilizando una granja de servidores web y las teclas de la máquina no están sincronizadas.

Otra posibilidad es que la fecha de montaje sea en el futuro. Esto conduce a todo tipo de problemas oscuros y vale la pena comprobarlo. Tal vez su servidor está en una zona horaria diferente?


Creo que estos errores ocurren con diferentes navegadores por diferentes razones, lo que hace que sea tan difícil de localizar.

Error IE8

Microsoft ha dicho que un error en IE8 (en algunas circunstancias) generará solicitudes falsas al servidor, que no afectan al usuario, pero conducen a que se registren errores en el lado del servidor.

Vea esta discusión aquí: Error IE8 - 4K eliminado - "Viewstate no válido" al cargar ScriptResource.axd (edición: el enlace ahora requiere inicio de sesión por algún motivo, lo siento)

... particularmente la actualización de EricLaw-MSFT cuando dice:

Vale la pena mencionar que cualquiera que esté experimentando un problema aquí en IE6 / IE7 o Firefox está encontrando un problema diferente que no está relacionado con el problema de IE8 que se describe a continuación.

Esta publicación del blog también describe los errores: Errores en Lookahead Downloader de IE8

Dicen que cambiar la forma en que establece Content-Type ayudará con algunos de los errores, aunque no todos: dicen que se debe a varias circunstancias oscuras que aún están observando.

Actualización: a partir del 01 / abril / 2010, estos errores de IE8 se han solucionado a través de la actualización acumulativa de IE8 (KB980182).
Esta publicación: IE8 Lookahead Downloader Fixed proporciona más detalles sobre los errores y otras soluciones posibles / parciales (por ejemplo, esta ) aparte de esperar a que todos en el mundo descarguen la solución.

Otros navegadores

Todavía no lo hemos resuelto, pero otros navegadores también están generando estos errores, probablemente por diferentes razones.

Granjas web

Este problema no se limita a los sitios que se ejecutan en granjas de servidores web, pero si está ejecutando una granja de servidores , verifique esta respuesta con jesal, que puede ayudar


El mismo error aquí para User-Agent: Mozilla / 4.0 (compatible; MSIE 7.0; AOL 9.0; Windows NT 6.0; Trident / 4.0; GTB5; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729 ; .NET CLR 3.0.30618)

Intenté modificar / eliminar la declaración de tipo de documento y deformar el javascript en // <! [CDATA [y todavía hay excepciones ...

Por el momento todo vino de la misma IP.


Esto puede suceder si el machineKey del grupo de aplicaciones que recibe la solicitud de scriptresource.axd es diferente al del grupo de aplicaciones que sirvió en la página original. Esto es más probable si está utilizando una granja de servidores web. También puede ocurrir en un solo servidor si el grupo de aplicaciones se reinicia, ya que se generará una nueva clave de máquina. La solución para cualquiera de los dos es poner un machineKey fijo en su web.config.


Me he dado cuenta de que Firefox 3.1 Beta causa errores de estado de vista no válidos. Es posible que desee revisar sus registros para ver qué navegador se está utilizando cuando ocurren estos errores.


Recibo los mismos errores, en realidad, apenas comenzaron en el último mes o dos, ha estado ocurriendo en un par de nuestros sitios y no hemos cambiado ninguno de ellos desde diciembre. Esto me hace pensar que un cambio de configuración o actualización de Windows lo está efectuando.


Sugeriría mirar this ... básicamente describe algunos casos en que esto puede suceder dependiendo del doctype. Tuvimos un problema similar, y parecía que solo aparecía de forma errática ... para nosotros era un conflicto entre nuestro doctype XHTML y el javascript que teníamos en la página. Pudimos resolverlo asegurándonos de que todo nuestro javascript estaba correctamente envuelto en etiquetas.

<script> mycode; </script>

se convertiría

<script> // <![CDATA[ mycode; // ]]> </script>

Puede que este no sea un problema idéntico, pero si tiene un doctype xhtml, vea si tiene caracteres que no hayan escapado que no sean XML legales en algún lugar (como los caracteres ''<'').


MS recomienda no declarar su conjunto de caracteres utilizando una etiqueta meta y establecerlo como un encabezado HTTP en su lugar.

Así que quita

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

y añadir

Response.AddHeader("Content-Type", "text/html; charset=utf-8");