Problema Viewstate errato non valido in un'applicazione .NET

Question

Mi sembra di avere un "viewstate non valido" di tanto in tanto nel Visualizzatore eventi per la mia applicazione ASP.NET.

La maggior parte (95%) sembra fare riferimento a ScriptResource.axd (l'applicazione utilizza la libreria ASP.NET AJAX). Non è possibile rimuovere la libreria Ajax o come Ajax è utilizzato ovunque ..

Come posso ridurre questi errori? Ricevo circa 100-200 errori al giorno e non ho idea di come risolverli! Vengono da diversi browser, diversi IP e posizioni geografiche.

È difficile per me riprodurre il problema perché a me è capitato a malapena, mi è capitato solo 3-4 volte di punto in bianco.

Errore:

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. 

Inoltre ottengo questo errore ogni tanto nel mio codice .NET che avviene al tempo stesso che potrebbe essere correlato:

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

Utilizzare una fissa tasto macchina (anche quando si esegue un singolo server).

Il problema si verifica quando si utilizza la configurazione automatica per la chiave della macchina, ne viene fornita una nuova ogni volta che il dominio dell'app viene riciclato. Ciò influisce sulla convalida dello stato di visualizzazione, sulla decodifica della stringa di query delle risorse dinamiche e sui ticket di autenticazione [inserire altri usi della chiave della macchina].

Answer 2

Ho visto problemi come questo quando il Viewstate è troppo grande. L'ho visto accadere a causa del problema descritto da Freddy.

In genere non mi piace l'idea di utilizzare Viewstate. Puoi disattivare completamente Viewstate?

Answer 3

Immagino che tu stia usando ASP.NET AJAX. Sto avendo lo stesso problema. Sporadicamente troverei questa eccezione nel mio registro eventi e il percorso richiesto è SEMPRE ScriptResource.axd.

L'utilizzo di validationKey e decryptionKey fissi in machineKey non ha risolto il problema.

In base a ciò che sono stato in grado di raccogliere, tendo a credere che questo errore non abbia nulla a che fare con ViewState di sorta; la mia teoria è che per qualche ragione, alcuni UA in qualche modo rovinano il parametro "d" di ScriptResource.axd. Il problema è facilmente replicabile richiedendo manualmente il percorso incriminato. Questo dà un'eccezione "ViewState non valido", anche se ViewState non si applica nemmeno qui.

Scavando attraverso i miei ceppi, ho trovato ad esempio:

Questa richiesta viene servita OK (200): /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NRCY1n0_DNg1nE6-DDbsD6r4EiuwoeDzp9mjDDfBNLb1k1 & t = 41df03cc

Questo anche una richiesta leggermente diversa è OK (200): /ScriptResource.axd?d = oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NR5ijsxQts4AfbJdACRwmQ8sHt6UAzui3spEnooPneTz01 & t = 41df03cc

Questa richiesta fallisce con una risposta 500 e l'eccezione ViewState non valido: /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_3 prodotti $ ctl00 $ AddToCart1 $ id

Se guarda da vicino, i primi caratteri su tutte e tre le richieste sono gli stessi, ma gli ultimi caratteri dell'ultima richiesta (in grassetto) sono chiaramente ID di controllo "prodotti $ ctl00 $ AddToCart1 $ id" (Ho un controllo chiamato prodotti e AddToCart). Non so come sia arrivato questo ID, ma nel mio caso questo è ciò che sta causando tutte queste eccezioni ViewState non valide.

Non sono sicuro se questo è lo stesso caso dell'OP o no, ma ho notato che l'URL di richiesta di Martin termina in "html", che è un po 'una coincidenza per un parametro che dovrebbe essere una chiave ...

Ho già mal di testa grazie a questo problema. E finora, il post più interessante che ho trovato è questo http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

Eventuali approfondimenti?

Answer 4

Ho anche questo problema, e ho provato tutto ciò che è stato menzionato in tutti i blog che ho trovato (codice fisso della macchina, dimensione del viewstate, ecc.). Il 99% delle volte l'errore viene registrato su richieste a ScriptResource.axd. Sto usando .net 3.5 SP1, sul server Win 2003. L'app è ospitata su due server identici paralleli, bilanciati 50/50. Ogni server ha la stessa chiave macchina.

Normalmente questo errore non mi riguarda molto, tuttavia, in un periodo di 3 mesi, la tendenza dell'occorrenza è andata verso l'alto.

Qualcuno pensa che questo errore sia correlato al Viewstate non essendo UrlEncoded/HtmlEncoded o UrlDecoded correttamente. Forse c'è un sottoinsieme di caratteri all'interno del viewstate che alcuni browser stanno sostituendo con qualche valore codificato. Non sono sicuro se ciò abbia senso ..

Answer 5

Stai utilizzando un sistema operativo non inglese?

Per alcuni motivi, il nome account di "NT Authority \ Network Service" è stato localizzato in altre lingue.
Purtroppo, molti programmi hanno il nome dell'account codificato con il nome inglese e non troveranno il servizio di rete quando sono in esecuzione su versioni esterne di Windows, portando a tutti i tipi di errori funky nel registro eventi.

Answer 6

Ho appena ridotto questo problema a un utente con l'antivirus Trend Micro e gli errori hanno iniziato a verificarsi dopo l'aggiornamento del suo software di tendenza micro il 21/05/2009. Nessun errore prima di questa data.

Answer 7

I problemi relativi allo stato dello schermo sono fastidiosi e frustranti. Ho notato che alcune persone hanno parlato di problemi con Viewstate in questa discussione. Quindi, ecco alcuni suggerimenti che puoi guardare in ordine.

1. avrei eco ciò Freddy Rios ha detto nel thread già. Assicurati di che hai hardcoded la chiave macchina . Ciò risolverà la vasta maggioranza di questi problemi con . La cosa importante di ScriptResource è che dovrebbe avere un parametro d e un parametro t nella stringa di query.Se è non c'è qualcos'altro che non va!

2. Non lasciare che l'utente postback fino fatto. Probabilmente potresti fare con javascript e un po 'di css. Dalla memoria, penso che ci sia un modo per farlo con un meta tag ma potrebbe essere solo IE.

3. Vorrei vedere che sta scaricando la risposta in anticipo. Penserei dopo lo che il gestore di script sarebbe il migliore. Ma potrebbe essere necessario sperimentare un bit.

4. Se il tuo stato di visualizzazione sembra gonfio, attiva la compressione GZip su IIS.

5. Se il ViewState è diventato davvero gonfio e non si può ottenere GZip compressione acceso/o ha un indesiderato effetto. Quindi è possibile comprimere e decomprimere lo stato di visualizzazione . http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx

6. Se che ancora ti lascia con un viewstate gonfio , si poteva guardare memorizzare il ViewState localmente. http://blog.arctus.co.uk/articles/2007/04/23/advanced-asp-net-storing-viewstate-in-a-database/ è un buon punto di partenza.

Answer 8

Questo sembra essere lo stesso problema IE8 che molte persone hanno riscontrato. Ciò che sembra accadere è che in qualche modo IE8 (sia nella modalità di rendering IE8 che nella modalità di compatibilità IE7) perderà 4096 byte dal centro del documento HTML e questo dato mancante causa questa eccezione (di solito lo si vede in una chiamata ScriptResource o WebResource) .

Ecco un bug report di Microsoft sulla questione: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997

ci sono anche un sacco di forum, blog, ecc messaggi su questo 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 risposto a questo problema:

Nota è un bug in Internet Explorer 8. Il team di Internet Explorer ha studiato questo problema.

Impatto: Finora, riteniamo che il problema non abbia alcun impatto sull'esperienza dell'utente finale con l'applicazione Web; l'unico effetto negativo sono le richieste spurie/malformate inviate dal motore di download speculativo di JavaScript. Quando lo script è effettivamente necessario al parser, verrà scaricato e utilizzato correttamente in quel momento.

circostanze: Il spurio-request sembra verificarsi solo in determinate situazioni di temporizzazione, solo quando un tag META http-equiv contenente un Content-Type con una direttiva CHARSET compare nel documento, e solo quando un URL JavaScript SRC comprende il 4096 ° byte del corpo della risposta HTTP.

Soluzione temporanea: Pertanto, attualmente riteniamo che questo problema possa essere mitigato dichiarando il CHARSET della pagina utilizzando l'intestazione Content-Type HTTP anziché specificarla all'interno della pagina.

Quindi, piuttosto che mettere

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

nel tag testa, invece, inviare la seguente intestazione della risposta HTTP:

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

Si noti che le specifiche del set di caratteri nei risultati di intestazione HTTP in miglioramento prestazioni in tutti i browser, poiché i parser del browser non devono riavviare l'analisi dall'inizio incontrando la dichiarazione del set di caratteri. Inoltre, l'utilizzo dell'intestazione HTTP aiuta a mitigare alcuni vettori di attacco XSS.

NOTA: È stato segnalato che questo problema si verifica ancora quando META HTTP-EQUIV non è presente nella pagina. Aggiorneremo questo commento quando avremo ulteriori indagini.

, pubblicato da Microsoft il 30/06/2009 alle 12:25.

Edit: vedo ancora questa eccezione di tanto in tanto, ma questo bug viene segnalato come fissi: http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

Answer 9

penso, è necessario utilizzare nella pagina 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"> 

Questo risolvere il mio problema

Answer 10

Il problema sembra essere il downloader lookahead in IE8.

Sembra interessare solo IE8 in una serie di circostanze piuttosto oscure. Uno dei motivi per cui può passare inosservato è che un blocco di dati di 4k aggiunto a un URL viene spesso scartato dal server. Una delle cose che sembra renderlo più probabile è una connessione di rete lenta. Qualcuno in una delle risorse sottostanti ha notato che aveva solo il problema con i suoi clienti in Nuova Zelanda.

Un sacco di persone che spiegano due problemi separati, uno dei quali è descritto nella domanda di cui sopra (URL malformati inviati al server):

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

articolo che spiega che il downloader lookahead è fisso:

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

KB980182 - aggiornamento cumulativo in cui problema viene risolto:

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

NOTA: Poiché lo script viene automaticamente ri-scaricati se non poteva essere recuperato il downloader lookahead, dovrebbe essere possibile per tornare alla modalità di vecchia convalida in cui axd file non sono stati controllati per la validità e rimuovere i sintomi del problema:

<httpRuntime requestValidationMode="2.0" />