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

viewstate que es (10)

¿Estás ejecutando un sistema de operación no inglés?

Por alguna razón, el nombre de la cuenta de "NT Authority / Network Service" se ha traducido a otros idiomas.
Lamentablemente, muchos programas tienen el nombre de la cuenta codificado de forma rígida para el nombre en inglés, y no encontrarán el servicio de red cuando se ejecutan en versiones extranjeras de Windows, lo que genera todo tipo de errores funky en el registro de eventos.

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 ScriptResource.axd referencia a ScriptResource.axd (la aplicación usa 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 pasó a mí, 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 recibo este error de vez en cuando en mi código .NET que ocurre al mismo tiempo y que podría estar relacionado:

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)

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 de micro de tendencia el 21/05/2009. Sin errores antes de esta fecha.

Creo que debes usar 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">

Esto soluciona mi problema

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.

Muchas personas explican dos problemas separados, uno de los cuales se describe en la pregunta anterior (URL mal formadas enviadas al servidor):

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

Artículo que explica que el programa de descarga de búsqueda anticipada es fijo:

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

KB980182 - Actualización acumulativa en la que se soluciona el problema:

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

NOTA: Debido a que la secuencia de comandos se vuelve a descargar automáticamente si no puede ser recuperada por el programa de descarga anticipada, debería ser posible volver al antiguo modo de validación en el que no se verificaron los archivos .axd y eliminar los síntomas de la problema:

<httpRuntime requestValidationMode="2.0" />

Este parece ser el mismo problema 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í hay un informe de error de Microsoft sobre el problema: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997

También hay muchas publicaciones en foros, blogs, etc. sobre este tema:

Microsoft ha respondido a este problema:

La 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 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 solicitud espuria parece producirse solo en determinadas situaciones de temporización, solo cuando aparece una etiqueta META HTTP-EQUIV que contiene un tipo de contenido con una directiva CHARSET en el documento, y solo cuando una URL SRC de JavaScript abarca el 4096o byte de la Cuerpo de respuesta HTTP

Solución: 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.

Entonces, en lugar de poner

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

En su etiqueta principal, en su lugar, envíe el siguiente encabezado de respuesta HTTP:

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

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

NOTA: Ha habido informes de que este problema aún 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/6/2009 a las 12:25 p.m.

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

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

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

Los problemas de Viewstate son molestos y frustrantes. He notado que algunas personas han hablado sobre problemas con Viewstate en este hilo. Entonces, aquí hay algunas sugerencias que puedes ver en orden.

Me haría eco de lo que Freddy Rios dijo en el hilo. Asegúrese de haber codificado la clave de la máquina. Esto resolverá la gran mayoría de estos problemas. Lo importante del enlace ScriptResource es que debe tener un parámetro de anuncio y un parámetro en la cadena de consulta. ¡Si no hay algo más, está mal!
No dejes que el usuario vuelva a publicar hasta que termines. Probablemente puedas hacer esto con javascript y un poco de css. Desde la memoria, creo que hay una manera de hacer esto con una metaetiqueta, pero podría ser solo IE.
Yo miraría está enjuagando la respuesta temprano. Pensaría después de que el administrador de guiones sería el mejor. Pero es posible que necesite experimentar un poco.
Si su viewstate parece hinchado, active la compresión GZip en IIS.
Si su viewstate se ha hinchado realmente y no puede activar la compresión GZip / o tiene un efecto secundario no deseado. Luego puede comprimir y descomprimir viewstate. http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx
Si eso aún te deja con un estado de vista saturado, podrías mirar almacenar el viewstate localmente. http://blog.arctus.co.uk/articles/2007/04/23/advanced-asp-net-storing-viewstate-in-a-database/ es un buen punto de partida.

Supongo que estás usando 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.

Usar fixed validationKey y decryptionKey en machineKey no me solucionó el problema.

En función de 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í.

Buscando en mis registros, encontré por ejemplo:

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

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

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

Si miras detenidamente, los primeros caracteres de las tres solicitudes son los mismos, pero los últimos caracteres de la última solicitud (en negrita) son claramente ID de control "productos $ ctl00 $ AddToCart1 $ id" (tengo un control llamado productos 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, 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?

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 en aumento.

¿Alguien cree que este error está relacionado con que Viewstate no está codificado en URL / HtmlEncoded o UrlDecoded 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 eso tiene sentido ...

Use una tecla de máquina fija (incluso cuando hace un solo servidor).

El problema ocurre cuando se utiliza 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].