.NET应用程序中的不稳定无效Viewstate问题

时间：2009-04-08 04:23:22

标签： c# .net asp.net viewstate

我似乎偶尔会在我的ASP.NET应用程序的事件查看器中收到“无效的viewstate”。

他们中的大多数（95％）似乎都在引用ScriptResource.axd（应用程序 使用ASP.NET AJAX库。我无法删除Ajax库，因为Ajax随处可用..

如何减少这些错误？我每天得到约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)

10 个答案:

答案 0 :(得分：36)

这似乎与许多人一直在经历的IE8问题相同。似乎发生的事情是，IE8（在IE8渲染模式和IE7兼容模式下）将以某种方式从HTML文档中间丢失4096个字节，这个缺失的数据会导致此异常（您通常会在ScriptResource或WebResource调用中看到这一点）

以下是有关此问题的Microsoft错误报告： https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997

此问题还有很多论坛，博客等帖子：

Microsoft已回应此问题：

注意是Internet Explorer 8中的错误.Internet Explorer团队一直在调查此问题。

影响力：到目前为止，我们认为该问题对最终用户使用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标头中的charset规范可以提高所有浏览器的性能，因为浏览器的解析器在遇到字符集声明时无需从头开始重新解析。此外，使用HTTP标头有助于缓解某些XSS攻击媒介。

注意：有报告称当页面上没有META HTTP-EQUIV时仍会出现此问题。当我们进行更多调查时，我们会更新此评论。

微软于2009年6月30日下午12:25发布。

编辑： 我偶尔会看到这个异常，但是这个bug被报告为已修复： http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

答案 1 :(得分：4)

我猜你正在使用ASP.NET AJAX。我有同样的问题。偶尔我会在我的事件日志中找到此异常，并且请求的路径始终是ScriptResource.axd。

在machineKey中使用固定的validationKey和decryptionKey并没有为我解决问题。

根据我能够收集的内容，我倾向于认为此错误与ViewState无关;我的理论是，由于某种原因，某些UAs以某种方式弄乱了ScriptResource.axd的“d”参数。通过手动请求违规路径可以轻松复制该问题。这给出了“无效的ViewState”异常，即使ViewState甚至不适用于此。

挖掘我的日志，我找到了例如：

此请求已正常（200）： /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NRCY1n0_DNg1nE6-DDbsD6r4EiuwoeDzp9mjDDfBNLb1k1&t=41df03cc

这个略有不同的请求也可以提供OK（200）： /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NR5ijsxQts4AfbJdACRwmQ8sHt6UAzui3spEnooPneTz01&t=41df03cc

此请求因500响应和无效ViewState异常而失败： /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_3products$ctl00$AddToCart1$id

如果仔细观察，这三个请求中的前几个字符是相同的，但最后一个请求的最后几个字符（粗体）显然是控制ID“产品$ ctl00 $ AddToCart1 $ id”（我有一个控制命名产品和AddToCart）。我不知道这个ID是如何到达那里的，但在我的情况下，这就是造成所有这些无效ViewState异常的原因。

我不确定这是否与OP相同，但我注意到Martin的请求URL以“html”结尾，这对于一个应该是关键的参数来说有点巧合。 ..

由于这个问题，我已经头疼了。到目前为止，我遇到的最有见地的帖子是http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

任何见解？

答案 2 :(得分：4)

Viewstate问题令人烦恼且令人沮丧 - 我注意到有一些人在这个帖子中讨论过Viewstate问题。所以，这里有一些你可以按顺序看的建议。

  1. 我会回应弗雷迪里奥斯所说的话 已经在线程中。确保 你已经硬编码了机器 键。这将解决广大问题 大多数这些问题。该 重要的是关于 ScriptResource链接就是它 应该有一个d参数和一个t 查询字符串中的参数。如果它 没有别的错误！

  2. 不要让用户回复直到 你做完了你可能会这样做 这与javascript和一点点 CSS。从记忆中，我认为有一个 用meta标签做这个的方法但是 它可能只是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/ 是一个很好的起点。

答案 3 :(得分：1)

使用固定的机器密钥（即使在执行单个服务器时）。

使用机器密钥的自动配置时会出现问题，每次回收应用程序域时都会出现一个新问题。这会影响视图状态验证，动态资源查询字符串解密和身份验证票据[插入机器密钥的其他用途]。

答案 4 :(得分：1)

当Viewstate太大时，我看到过这样的问题。我已经看到它因弗雷迪所描述的问题而发生。

我一般不喜欢使用Viewstate。你能完全关闭Viewstate吗？

答案 5 :(得分：1)

我也遇到了这个问题，我已经尝试了我发现的所有博客中提到的所有内容（固定机器密钥，视图状态大小等）。 99％的时间将错误记录在对ScriptResource.axd的请求上。我在Win 2003服务器上使用.net 3.5 SP1。该应用程序托管在两个平行的相同服务器上，平衡50/50。每台服务器都有相同的机器密钥。

通常这个错误并不关心我，但是，在3个月的时间里，出现的趋势一直在上升。

是否有人认为此错误与Viewstate未正确编写UrlEncoded / HtmlEncoded或UrlDecoded有关。也许在视图状态中有一些字符子集，某些浏览器正在替换某些编码值。我不确定这是否有意义......

答案 6 :(得分：1)

我认为，你必须在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">

这解决了我的问题

答案 7 :(得分：0)

你在运行非英语操作系统吗？

由于某些原因，“NT Authority \ Network Service”的帐户名已使用其他语言进行了本地化 遗憾的是，许多程序的帐户名称都硬编码为英文名称，在外国版Windows上运行时找不到网络服务，导致事件日志中出现各种时髦错误。

答案 8 :(得分：0)

我刚刚将这个问题缩小到了使用趋势科技防病毒软件的用户，并且在他于2009年5月21日更新了趋势科技软件后，错误才开始发生。在此日期之前没有错误。

答案 9 :(得分：0)

问题似乎是IE8中的前瞻性下载。

它似乎只会在相当模糊的环境中影响IE8。可以忽略的一个原因是服务器经常丢弃附加到URL的4k块数据。似乎使其更有可能的一个原因是网络连接速度缓慢。下列资源中的某人注意到他只在新西兰遇到了他的客户问题。

很多人解释了两个不同的问题，其中一个在上面的问题中描述（发送到服务器的格式错误的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

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

<httpRuntime requestValidationMode="2.0" />
相关问题
最新问题