在.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

此外,在这个问题上有很多论坛,博客等职位:


微软已经回应了这个问题:

请注意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议你可以看看。

  1. 我会回应弗雷迪·里奥斯已经在线上说。 确保您已经对机器密钥进行了硬编码。 这将解决绝大多数这些问题。 关于ScriptResource链接的重要一点是它应该有查询string中的广告参数和参数。 如果没有别的错误!

  2. 不要让用户回发,直到完成。 你可能可以用javascript和一些CSS做到这一点。 从内存中,我认为有一种方法可以用meta标签来做到这一点,但它可能只是IE浏览器。

  3. 我会看早期的冲动反应。 我会认为脚本经理会是最好的。 但是你可能需要尝试一下。

  4. 如果您的viewstate看起来很臃肿,请打开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/是一个很好的起点。;

使用一个固定的机器键(即使在做单个服务器时)。

使用机器密钥的自动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://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

注:因为如果前瞻式下载程序无法检索脚本,脚本会自动重新下载,所以应该可以更改回旧的validation模式,其中.axd文件未检查有效性并删除问题:

 <httpRuntime requestValidationMode="2.0" />