web-dev-qa-db-ja.com

.NETアプリケーションでの不安定なViewstateの問題

ASP.NET アプリケーションのイベントビューアーで時々「無効なビューステート」を取得しているようです。

それらのほとんど（95％）はScriptResource.axdを参照しているようです（アプリケーションは ASP.NET AJAX ライブラリを使用しています）。 Ajaxはどこでも使用されているため、 Ajax ライブラリを削除する方法はありません。

これらのエラーを減らすにはどうすればよいですか？ 1日に100〜200のエラーが発生しますが、それらを修正する方法がわかりません。それらは、異なるブラウザ、異なるIP、および地理的な場所から来ています。

問題が発生したことはほとんどないため、問題を再現するのは困難です。突然発生したのは3〜4回だけです。

エラー：

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.

また、関連する可能性のある同時発生する.NETコードでこのエラーが時々発生します。

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)
c#.netasp.netviewstate
61
Martin

これは、多くの人が経験している同じIE8の問題のようです。どうやらIE8（IE8レンダリングモードとIE7互換モードの両方で）がHTMLドキュメントの中央から4096バイトを失い、このデータが欠落するとこの例外が発生します（通常、これはScriptResourceまたはWebResource呼び出しで表示されます） 。

この問題に関するマイクロソフトのバグレポートは次のとおりです。 https://connect.Microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997

また、この問題に関する多くのフォーラム、ブログなどの投稿があります。

マイクロソフトはこの問題に対応しています。

注はInternet Explorer 8のバグです。InternetExplorerチームはこの問題を調査しています。

Impact：これまでのところ、この問題はエンドユーザーのWebアプリケーションのエクスペリエンスに影響を与えないと考えています。唯一のマイナスの影響は、JavaScriptの投機的ダウンロードエンジンによって送信された偽の/不正なリクエストです。スクリプトが実際にパーサーに必要な場合、その時点で適切にダウンロードされて使用されます。

状況：スプリアスリクエストは、CHARSETディレクティブを持つContent-Typeを含むMETA HTTP-EQUIVタグが特定のタイミングの状況でのみ発生するようです。ドキュメントに表示されますが、JavaScript SRC URLがHTTP応答本文の4096番目のバイトにまたがっている場合のみです。

回避策：したがって、現時点では、HTTP Content-Typeヘッダーを使用してページのCHARSETを宣言することで、この問題を軽減できると考えていますページ。

だから、置くよりも

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

代わりに、headタグで、次のHTTP応答ヘッダーを送信します。

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

HTTPヘッダーの文字セットを指定すると、ブラウザーのパーサーが文字セット宣言を検出したときに最初から解析を再開する必要がないため、すべてのブラウザーでパフォーマンスが向上することに注意してください。さらに、HTTPヘッダーを使用すると、特定のXSS攻撃ベクトルを緩和できます。

注：META HTTP-EQUIVがページにない場合でも、この問題が発生するという報告があります。さらなる調査がある場合、このコメントを更新します。

Microsoftによる2009年6月30日12:25 PMの投稿。

編集：私はまだこの例外を時々見ますが、このバグは修正されていると報告されています： http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader- fixed.aspx

36
Jim Petkus

ASP.NET AJAXを使用していると思います。私は同じ問題を抱えています。散発的に、この例外はイベントログにあり、要求されたパスは常にScriptResource.axdです。

MachineKeyで固定のvalidationKeyとdecryptKeyを使用しても、問題は解決しませんでした。

収集できたものに基づいて、このエラーはViewStateとはまったく関係ないと考えがちです。私の理論では、何らかの理由で、特定のUAがScriptResource.axdの「d」パラメーターを何らかの方法で台無しにしているということです。問題は、問題のパスを手動で要求することで簡単に再現できます。 ViewStateはここでも適用されませんが、これにより「無効なViewState」例外が発生します。

ログを掘り下げてみたところ、たとえば次のことがわかりました。

このリクエストは正常に処理されます（200）：/ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NR1D6Dddddd6dddd6ddd6ddd6dd6ddd6ddd6dd6dd6dd6ddd6dd6dd6dd6ddd6dd6ddd6dd6dd6dd6dd11dについて

このわずかに異なる要求をも提供していますOK（200）：/ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NR5ijsxQts4AfbJdACRwmQ8sHt6UAzui3spEnooPneTz01&t=41df03cc

この要求は500応答および無効なViewState例外で失敗します：/ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_3products$ctl00$AddToCart1$id

よく見ると、3つのリクエストすべての最初の数文字は同じですが、最後のリクエストの最後の数文字（太字）は明らかにコントロールID "products $ ctl00 $ AddToCart1 $ id"です（私はproductsという名前のコントロールを持っていますおよびAddToCart）。このIDがどのようにそこに到達したかはわかりませんが、私の場合、これがこれらのすべての無効なViewState例外の原因です。

これがOPと同じケースかどうかはわかりませんが、MartinのリクエストURLが「html」で終わることに気付きます。これは、キーになるはずのパラメータの偶然の一致です...

この問題のおかげで、すでに頭痛の種があります。これまでのところ、私が出会った最も洞察に満ちた投稿はこれです http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

洞察はありますか？

4
Daniel Liuzzi

Viewstateの問題は迷惑でイライラします。このスレッドでViewstateの問題について話している人がいることに気付きました。そのため、順番に確認できるいくつかの提案があります。

  1. 私はフレディ・リオスがすでにスレッドで言ったことをエコーし​​ます。マシンキーをハードコーディングしたことを確認してください。これにより、これらの問題の大部分が解決されます。 ScriptResourceリンクに関する重要なことは、クエリ文字列にdパラメーターとtパラメーターが必要であることです。そうでない場合は、他の何かが間違っています！

  2. 完了するまでユーザーにポストバックさせないでください。あなたはおそらくJavaScriptと少しのCSSでこれを行うことができます。メモリから、メタタグを使用してこれを行う方法はあると思いますが、IEのみです。

  3. 応答を早期にフラッシュすることを検討します。スクリプトマネージャーが最適だと思います。しかし、少し実験する必要があるかもしれません。

  4. ビューステートが肥大しているように見える場合は、IISでGZip圧縮をオンにします。

  5. ビューステートが本当に肥大化していて、GZip圧縮をオンにできない場合、または望ましくない副作用がある場合。その後、ビューステートを圧縮および圧縮解除できます。 http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx

  6. それでも肥大化したビューステートが残る場合は、ビューステートをローカルに保存することを検討できます。 http://blog.arctus.co.uk/articles/2007/04/23/advanced-asp-net-storing-viewstate-in-a-database/ は良い出発点です。

4
Martin Clarke

私は、あなたが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">

これは私の問題を解決します

1
Sergio

Viewstateが大きすぎると、このような問題が発生します。 Freddyが説明する問題のせいで起こることがあります。

私は通常、Viewstateを使用するという考えを嫌います。 Viewstateを完全にオフにできますか？

1
Esteban Araya

私もこの問題を抱えており、見つけたすべてのブログに記載されているすべてのことを試しました（マシンキーの修正、ビューステートのサイズなど）。 ScriptResource.axdへのリクエストでエラーが記録される時間の99％。 Win 2003サーバーで.net 3.5 SP1を使用しています。このアプリは、バランスの取れた50/50の2つの並列同一サーバーでホストされます。各サーバーには同じマシンキーがあります。

通常、このエラーは私にはあまり関係ありませんが、3か月以上にわたって、発生の傾向は大きくなっています。

このエラーは、ViewstateがUrlEncoded/HtmlEncodedまたはUrlDecodedが正しくないことに関係していると思いますか。おそらく、一部のブラウザがエンコードされた値に置き換えられているというビューステート内の文字サブセットがあります。それが理にかなっているかどうかはわかりません。

1
Derek

固定マシンキーを使用します（単一サーバーを実行する場合でも）。

この問題は、マシンキーの自動構成を使用する場合に発生し、アプリドメインがリサイクルされるたびに新しい構成を取得します。これは、ビューステートの検証、動的リソースクエリ文字列の復号化、認証チケットに影響します[マシンキーの他の使用を挿入]。

1
eglasius

この問題をTrend Microウイルス対策ソフトウェアを使用しているユーザーに絞り込んだところ、2009年5月21日にTrend Microソフトウェアを更新した直後にエラーが発生し始めました。この日付の前にエラーはありません。

0
JohnnyCantCode

問題は、IE8の先読みダウンローダーのようです。

かなりあいまいな状況でのみIE8に影響するようです。気付かれない理由の1つは、URLに追加されたデータの4kチャンクがサーバーによって破棄されることが多いことです。可能性を高めると思われることの1つは、低速なネットワーク接続です。以下のリソースのいずれかの誰かが、彼はニュージーランドのクライアントにのみ問題があると指摘しました。

上記の質問（サーバーに送信された不正なURL）で説明されている2つの問題を説明する多くの人々：

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

先読みダウンローダーが修正されたことを説明する記事：

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

KB980182–問題が修正された累積的な更新：

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

注：先読みダウンローダーで取得できなかった場合、スクリプトは自動的に再ダウンロードされるため、古いものに戻すことができるはずです.axdファイルの有効性が確認されず、問題の症状を取り除く検証モード：

<httpRuntime requestValidationMode="2.0" />
0
Jonathan

英語以外のオペレーティングシステムを実行していますか？

何らかの理由で、「NT Authority\Network Service」のアカウント名は他の言語にローカライズされています。
残念なことに、多くのプログラムは英語の名前にハードコードされたアカウント名を持ち、Windowsの外国バージョンで実行するときにネットワークサービスを見つけられず、イベントログにあらゆる種類のファンキーなエラーが発生します。

0
Sam