Problème Erratic Invalid Viewstate dans une application .NET

Question

Il semble que je reçoive de temps en temps un message "invalid viewstate" dans l'observateur d'événements pour mon site Web. ASP.NET application.

La plupart d'entre eux (95%) semblent faire référence à ScriptResource.axd (l'application utilise le ASP.NET AJAX bibliothèque). Il n'y a aucun moyen de supprimer le Ajax bibliothèque soit car Ajax est utilisé partout..

Comment puis-je réduire ces erreurs ? Je reçois ~ 100-200 erreurs par jour et je n'ai aucune idée de la façon de les corriger ! Elles proviennent de différents navigateurs, de différentes IP et de différents lieux géographiques.

Il m'est difficile de reproduire le problème car il m'est à peine arrivé, il ne m'est arrivé que 3-4 fois de façon inattendue.

Erreur :

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.

J'obtiens également cette erreur de temps en temps dans mon code .NET qui se produit en même temps, ce qui pourrait être lié :

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

J'ai également ce problème, et j'ai essayé tout ce qui est mentionné dans tous les blogs que j'ai trouvés (clé de machine fixe, taille du viewstate, etc.). Dans 99% des cas, l'erreur est enregistrée sur les requêtes à ScriptResource.axd. J'utilise .net 3.5 SP1, sur un serveur Win 2003. L'application est hébergée sur deux serveurs parallèles identiques, équilibrés à 50/50. Chaque serveur a la même clé de machine.

Normalement, cette erreur ne me préoccupe pas beaucoup, mais sur une période de trois mois, la tendance à l'occurrence a augmenté.

Est-ce que quelqu'un pense que cette erreur est liée au fait que le Viewstate n'est pas UrlEncoded/HtmlEncoded ou UrlDecoded correctement. Peut-être y a-t-il un sous-ensemble de caractères dans le Viewstate que certains navigateurs remplacent par une valeur codée. Je ne suis pas sûr que cela ait un sens

Answer 2

Je pense que vous devez l'utiliser dans une page 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">

Cela résout mon problème

Answer 3

Utilisez-vous un système d'exploitation non anglais ?

Pour certaines raisons, le nom de compte de "NT Authority". \Network Service" a été localisé dans d'autres langues.
Malheureusement, de nombreux programmes ont le nom du compte codé en dur avec le nom anglais, et ne trouvent pas le service réseau lorsqu'ils sont exécutés sur des versions étrangères de Windows, ce qui entraîne toutes sortes d'erreurs bizarres dans le journal des événements.

Answer 4

Je viens de réduire ce problème à un utilisateur avec un antivirus Trend Micro et les erreurs ont commencé à se produire après qu'il ait mis à jour son logiciel Trend Micro le 21/5/2009. Aucune erreur avant cette date.

Answer 5

Le problème semble être le téléchargeur lookahead dans IE8.

Il semble qu'il n'affecte IE8 que dans un ensemble de circonstances assez obscures. L'une des raisons pour lesquelles il peut passer inaperçu est qu'un morceau de données de 4k ajouté à une URL est souvent rejeté par le serveur. L'une des choses qui semble rendre ce problème plus probable est une connexion réseau lente. Quelqu'un dans l'une des ressources ci-dessous a noté qu'il n'avait ce problème qu'avec ses clients en Nouvelle-Zélande.

Beaucoup de personnes expliquent deux problèmes distincts, dont l'un est décrit dans la question ci-dessus (URLs malformées envoyées au serveur) :

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

Article expliquant que le téléchargeur lookahead est corrigé :

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

KB980182 - Mise à jour cumulative dans laquelle le problème est corrigé :

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

NOTE : Comme le script est automatiquement retéléchargé s'il n'a pas pu être récupéré par le téléchargeur lookahead, il devrait être possible de revenir à l'ancien mode de validation dans lequel la validité des fichiers .axd n'était pas vérifiée et de supprimer les symptômes du problème :

<httpRuntime requestValidationMode="2.0" />