Fixed bug with invalid view in .NET application.

Question

It seems I get an “invalid view” every time in the event viewer for an ASP.NET application.

Most of them (95%) seem to reference ScriptResource.axd (the application uses the ASP.NET AJAX library). I cannot remove the Ajax library either as Ajax is used everywhere.

How can I reduce these errors? I get ~ 100-200 errors a day, and I have no idea how to fix them! They come from different browsers, different IP addresses and geographical locations.

It’s hard for me to reproduce the problem, because it hardly happened to me, it only happened to me 3-4 times because of the blue.

Mistake:

 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. 

I also get this error from time to time in my .NET code, which happens at the same time, which may be related:

 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

This seems to be the same IE8 problem as many people have. Something similar to the fact that IE8 (both in IE8 rendering mode and in IE7 compatibility mode) will lose 4096 bytes from the middle of the HTML document, and this missing data leads to this exception (usually you see this in a ScriptResource call or WebResource).

Here is a Microsoft bug report on this: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=434997

There are also many posts in the forum, blog, etc. on this issue:

• Invalid Webresource.axd Settings
• IE 8 removes memory pages
• http://forums.asp.net/t/1373410.aspx?PageIndex=1
• http://forums.asp.net/p/1409964/3085329.aspx

---

Microsoft answered this problem:

Note - This is a bug in Internet Explorer 8. The Internet Explorer team is investigating this issue.

Influence . So far, we believe that the problem does not affect the end-user experience in the web application; the only negative effect is false / garbled requests sent by speculative JavaScript loading engine. When the parser really needs the script, it will be loaded and used correctly at this time.

Circumstances : A false request appears only in certain synchronization situations, only when a META HTTP-EQUIV tag containing a Content-Type with the CHARSET directive appears in the document, and only when the JavaScript SRC URL covers the 4096th byte of the HTTP response body.

Workaround: Therefore, we currently believe that this problem can be mitigated by declaring the CHARSET of the page using the HTTP Content-Type header, rather than specifying it on the page.

So instead of posting

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

In your head tag, instead send the following HTTP response header:

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

Note that the encoding specification in the HTTP header improves performance in all browsers since browser parsers do not need to restart parsing from the very beginning when they encounter a character set declaration. Additionally, using an HTTP header helps mitigate some XSS attack vectors.

NOTE. There are reports that this problem still occurs when META HTTP-EQUIV is not on the page. We will update this comment when we have more research.

Submitted by Microsoft on 06/30/2009 at 12:25.

Edit: Sometimes I see this exception, but this error is reported as fixed: http://blogs.msdn.com/b/ieinternals/archive/2010/04/01/ie8-lookahead-downloader-fixed.aspx

Answer 2

I assume you are using ASP.NET AJAX. I have the same problem. Sporadically, I would find this exception in my event log, and the requested path is ALWAYS ScriptResource.axd.

Using fixed validationKey and decryptionKey in machineKey did not fix the problem for me.

Based on what I was able to compile, I am inclined to believe that this error has nothing to do with ViewState; my theory is that for some reason some UAs somehow messed up the "d" parameter of ScriptResource.axd. The problem is easily replicated by querying the violation path manually. This gives the exception "Invalid ViewState", although the ViewState is not even applied here.

Delving into my magazines, I found, for example:

This request is serviced by OK (200): /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NRCY1n0_DNg1nE6-DDbsD6r4zfjwjdj1jfjwjdj1w1jfjwjdj1jfjww1

This slightly different request is also made by OK (200): /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_33Y_9Dq6i10g9Q1NR5ijsxQts4AfbJdACRwmUzptjtfjtjfjtjfjtfjtfc

This request is not executed with a response of 500 and an Invalid ViewState exception: /ScriptResource.axd?d=oFCAB7_vUyp7Hhe9lxZBz37lpoAxhfbWwwdfFy3Zd3z41W_3 products $ ctl00 $ AddToCart1 $ id

If you look closely, the first few characters for all three requests are the same, but the last few characters of the last request (in bold) are clearly identifiers of the Control ID "products $ ctl00 $ AddToCart1 $ id" (I have controls for the named products and AddToCart). I don't know how this identifier got there, but in my case, this is what causes all of these Invalid ViewState exceptions.

I'm not sure if this is the same case as OP or not, but I noticed that the Martin request URL ends in "html", which is a match for the parameter, which should be the key ...

I already have a headache due to this problem. And so far, the most insightful entry I've come across is http://bytes.com/topic/asp-net/answers/861764-invalid-viewstate-system-string-decryptstringwithiv

Any ideas?

Answer 3

Problems with Viewstate are annoying and frustrating - I noticed that several people talked about Viewstate problems in this thread. So, here are some tips you can look at in order.

• I would say that Freddy Rios said in the stream already. Make sure that you hard-coded the car key. This will solve most of these issues. The important thing about a ScriptResource reference is that it must have the d parameter and the t parameter in the request. If it does nothing else!

• Do not let the user return your done. You could probably do this with javascript and some CSS. From memory, I think there is a way to do this using the meta tag, but it can only be IE.

• I would have looked, this is an answer early. I would have thought after the script manager it would have been better. But you may have to experiment a bit.

• If your viewstate looks bloated, enable GZip compression in IIS.

• If your viewstate has become really bloated and you cannot get gzip compression enabled / or it has unwanted side effects. Then you can compress and decompress ViewState. http://www.codeproject.com/KB/viewstate/ViewStateCompression.aspx

• If this still leaves you with a bloated look, you can look at keeping a local viewing area. http://blog.arctus.co.uk/articles/2007/04/23/advanced-asp-net-storing-viewstate-in-a-database/ is a good starting point.

Answer 4

Use a fixed machine key (even when running a single server).

The problem arises when using the automatic configuration for the machine key, you get a new one every time the application domain is processed. This affects the validation of view views, decryption of the query string of dynamic resources, and authentication tickets [insert other options for using the machine key].

Answer 5

I saw such problems when Viewstate is too large. I saw how this happened due to the problem that Freddy describes.

I generally don't like the idea of ​​using Viewstate. Can you completely disable ViewState?

Answer 6

I also have this problem and I tried everything that was mentioned in all found blogs (fixed machine key, view size, etc.). 99% of the time when an error is logged in ScriptResource.axd requests. I use .net 3.5 SP1, on a Win 2003 server. The application is hosted on two parallel identical servers, balanced 50/50. Each server has the same machine key.

Usually this error does not concern me much, however, over the 3-month period, the tendency for events to occur is up.

Does anyone think this error is due to ViewState not using UrlEncoded / HtmlEncoded or UrlDecoded correctly. Perhaps there is a subset of characters in the view that some browsers replace with some encoded value. I'm not sure if that even makes sense.

Answer 7

I think you should use on an aspx page:

 <!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"> 

It solves my problem

Answer 8

Do you work on a non-English operating system?

For some reason, the NT / Network Service account name is localized in other languages.
Unfortunately, many programs have an account name that is hardcoded in English and will not find the Network Service when working on other versions of Windows, which will result in all errors in the event log.

Answer 9

I just narrowed down this problem for a user with Trend Micro antivirus, and errors only started to occur after he updated his firmware on 5/21/2009. No errors until this date.

Answer 10

The problem looks like a bootloader in IE8.

This seems to only affect IE8 in a rather obscure set of circumstances. One of the reasons why this might go unnoticed is that the 4k chunk of data added to the URL is often dropped by the server. One of the things that seems to make it more likely is a slow network connection. Someone from one of the following resources noted that he only had a question with his clients in New Zealand.

A lot of people explain two separate problems, one of which is described in the question above (invalid URLs sent to the server):

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

An article explaining that a fixed bootloader has been fixed:

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

KB980182 . Cumulative update in which the problem is fixed:

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

NOTE. . Since the script is automatically reloaded if it cannot be loaded by the lookahead loader, it should be possible to return to the old scan mode in which the .axd files were not validated and fix the symptoms of the problem:

 <httpRuntime requestValidationMode="2.0" />