在.NET应用程序中的不稳定无效的Viewstate问题
我好像在我的ASP.NET应用程序的事件查看器中不时出现“无效的viewstate”。
他们大多数（95％）似乎是引用ScriptResource.axd （应用程序使用ASP.NET AJAX库）。 我无法移除Ajax库，因为无处不在使用Ajax。
我怎样才能减less这些错误？ 我每天发生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)
这似乎是许多人一直在遇到的IE8问题。 看来发生的事情是，不知何故IE8（在IE8渲染模式和IE7兼容模式下）将从HTML文档的中间失去4096个字节，这个缺失的数据导致这个exception（你通常在ScriptResource或WebResource调用中看到这个） 。
这里是关于这个问题的微软错误报告： https : //connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997
此外，在这个问题上有很多论坛，博客等职位：
- 无效的Webresource.axd参数正在生成
- IE 8掉内存页面？
- http://forums.asp.net/t/1373410.aspx?PageIndex=1
- http://forums.asp.net/p/1409964/3085329.aspx
微软已经回应了这个问题：
请注意Internet Explorer 8中的一个错误。Internet Explorer小组一直在调查此问题。
影响 ：迄今为止，我们认为这个问题不会影响最终用户使用networking应用的体验。 唯一的负面影响是由JavaScript推测下载引擎发送的虚假/畸形的请求。 当parsing器实际需要该脚本时，它将被正确地下载和使用。
情况 ：只有在特定的时间情况下才会出现虚假请求，只有在文档中出现包含具有CHARSET指令的Content-Type的META HTTP-EQUIV标记时，并且只有当JavaScript SRC URL跨越第4096个字节HTTP响应正文。
解决方法：因此，我们目前认为可以通过使用HTTP Content-Type标头声明页面的CHARSET而不是在页面内指定它来缓解这个问题。
所以，而不是放在
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">
在你的头标签中，相反，发送下面的HTTP响应头：
Content-Type: text/html; charset=utf-8
请注意，HTTP标头中的字符集指定可以提高所有浏览器的性能，因为在遇到字符集声明时，浏览器的parsing器不需要重新开始parsing。 此外，使用HTTP标头有助于缓解某些XSS攻击媒介。
注意：有报告说当META HTTP-EQUIV不在页面上时，这个问题仍然会发生。 当我们有更多的调查时，我们会更新这个评论。
由微软发布于2009年6月30日下午12:25。
编辑：我偶尔也会看到这个exception，但是这个bug报告是被修正的： http : //blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx
我想你正在使用ASP.NET AJAX。 我有同样的问题。 偶尔我会在我的事件日志中发现这个exception，并且请求的path是ALWAYS ScriptResource.axd。
在machineKey中使用固定的validationKey和decryptionKey并没有解决我的问题。
基于我能够收集的内容，我倾向于认为这个错误与ViewState无关; 我的理论是，由于某种原因，某些UA以某种方式混淆了ScriptResource.axd的“d”参数。 该问题很容易通过手动请求违规path来复制。 这给了一个“无效的ViewState”exception，即使ViewState甚至不适用于此。
挖掘我的日志，我发现例如：
此请求已成功（200）：/ ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NRCY1n0_DNg1nE6-DDbsD6r4EiuwoeDzp9mjDDfBNLb1k1&t=41df03cc
（200）：/ ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NR5ijsxQts4AfbJdACRwmQ8sHt6UAzui3spEnooPneTz01&t=41df03cc
此请求因500响应和无效的ViewStateexception而失败： /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_3 products $ ctl00 $ AddToCart1 $ id
如果仔细观察，所有三个请求的前几个字符是相同的，但最后一个请求（粗体）的最后几个字符显然是控制ID“products $ ctl00 $ AddToCart1 $ id”（我有一个控件命名产品和AddToCart）。 我不知道这个ID如何到达那里，但在我的情况下，这是什么导致所有这些无效的ViewStateexception。
我不确定这是否与OP相同，但我注意到Martin的请求URL以“html”结尾，这对于一个被认为是关键字的参数是一个巧合。
由于这个问题，我已经头疼了。 到目前为止，我遇到的最有见地的post是这个http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv
任何见解？
视图状态问题令人讨厌和沮丧 – 我注意到有几个人在这个线程中讨论过Viewstate问题。 所以，这里有一些build议你可以看看。
-
我会回应弗雷迪·里奥斯已经在线上说。 确保您已经对机器密钥进行了硬编码。 这将解决绝大多数这些问题。 关于ScriptResource链接的重要一点是它应该有查询string中的广告参数和参数。 如果没有别的错误！
-
不要让用户回发，直到完成。 你可能可以用javascript和一些CSS做到这一点。 从内存中，我认为有一种方法可以用meta标签来做到这一点，但它可能只是IE浏览器。
-
我会看早期的冲动反应。 我会认为脚本经理会是最好的。 但是你可能需要尝试一下。
-
如果您的viewstate看起来很臃肿，请打开IIS中的GZip压缩。
-
如果您的视图状态变得非常臃肿，并且您无法打开GZip压缩/或者出现不希望的副作用。 然后你可以压缩和解压视图状态。 http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx
-
如果这仍然让你的视图状态变得臃肿，那么你可以在本地存储视图状态。 http://blog.arctus.co.uk/articles/2007/04/23/advanced-asp-net-storing-viewstate-in-a-database/是一个很好的起点。;
使用一个固定的机器键（即使在做单个服务器时）。
使用机器密钥的自动configuration时会出现问题，每次应用程序域被回收时都会得到一个新的问题。 这会影响视图状态validation，dynamic资源查询string解密和authentication票据[插入机器密钥的其他用途]。
当ViewState太大时，我看到过这样的问题。 由于弗雷迪所描述的问题，我已经看到了这一点。
我一般不喜欢使用Viewstate的想法。 你能完全closuresViewstate吗？
我也有这个问题，我已经尝试了所有我发现的博客（固定的机器键，视图状态大小等）中提到的一切。 99％的错误logging到ScriptResource.axd的请求上。 我在Win 2003服务器上使用.net 3.5 SP1。 该应用程序托pipe在两个平行相同的服务器，平衡50/50。 每台服务器都有相同的机器密钥。
通常这个错误对我来说并不重要，但是在3个月的时间里，发生的趋势一直在上升。
有没有人认为这个错误是相关的Viewstate不正确UrlEncoded / HtmlEncoded或UrlDecoded。 也许在视图状态中有一些字符子集，一些浏览器正在用一些编码值replace。 我不确定这是否有道理
我想，你必须在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">
这解决了我的问题
你正在运行一个非英文的操作系统吗？
由于某些原因，“NT Authority \ Network Service”的帐户名称已被本地化为其他语言。
可悲的是，很多程序都将帐户名称硬编码为英文名称，并且在外部版本的Windows上运行时无法findnetworking服务，从而导致事件日志中出现各种各样的时髦错误。
我刚刚把这个问题缩小到了趋势科技杀毒软件的用户身上，而在5/21/2009更新趋势科技软件之后，这个错误才刚刚出现。 在这个date之前没有错误。
这个问题似乎是IE8中的前瞻式下载器。
这似乎只影响IE8在一个相当模糊的情况下。 可以忽略的一个原因是，附加到URL的4k数据块经常被服务器丢弃。 似乎更容易造成networking连接速度慢的原因之一。 以下资源中的某个人指出，他只在新西兰与其客户有关。
很多人解释两个单独的问题，其中之一在上面的问题中描述（发送到服务器的格式不正确的URL）：
文章解释说，前瞻下载器是固定的：
http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx
KB980182 – 修正了哪个问题的累积更新：
http://support.microsoft.com/kb/980182
注：因为如果前瞻式下载程序无法检索脚本，脚本会自动重新下载，所以应该可以更改回旧的validation模式，其中.axd文件未检查有效性并删除问题：
<httpRuntime requestValidationMode="2.0" />
