UpdatePanel Postback Error: Sys.WebForms.PageRequestManagerParserErrorException

Question

Already looked at this: Sys.WebForms.PageRequestManagerParserErrorException - what it is and how to avoid it

Problem is that it's only happening on my dev box. Two other developers are fine.

It's consistent and reproducible - I've tried deleting temporary internet files, deleted my obj and bin files and rebooting.

The response is clearly truncated when I look at it in the debugger when it hits the error.

Where else do I need to check to clear/clean out?

The error I'm seeing in the code is:

Microsoft JScript runtime error: Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled. Details: Error parsing near ' </tr> '.

_endPostBack: function PageRequestManager$_endPostBack(error, executor, data) {
    if (this._request === executor.get_webRequest()) {
        this._processingRequest = false;
        this._additionalInput = null;
        this._request = null;
    }

    var eventArgs = new Sys.WebForms.EndRequestEventArgs(error, data ? data.dataItems : {}, executor);
    Sys.Observer.raiseEvent(this, "endRequest", eventArgs);
    if (error && !eventArgs.get_errorHandled()) {
        throw error; // THIS IS WHERE THE ERROR IS THROWN
    }
},

This is during an Ajax postback.

1. There are no Response.Write calls.

2. I'm using Cassini/VS 2010 Development Server, how do I tell if there are filters?

3. ditto

4. Server trace is not enabled

5. No calls to Server.Transfer

In firebug, I can see that the response to the POST is truncated. Problem happens in Firefox or IE, and whether I'm debugging in VS or not.

The problem does go away if I switch to IIS Express in Visual Studio, and then it returns when I am back on the ASP.NET Development Server.

Solution 1

After our talk, my idea was that maybe for some reason the cassini can not hold a big post back field, and a big one is the viewstate.

So if the viewstate is a very big one maybe this is the problem.

A second case maybe if the viewstate contain characters that some time not pass by the router or some firewall and cut them as possible attach or virus.

Possible solutions: To compress the viewstate, and/or to cut it in smaller parts.

You can also download the latest developer edition version of Cassini with lot of improvements at http://cassinidev.codeplex.com/ that maybe have fix this issue.

Solution 2

I have seen this problem before with Cassini. I solved it by adding the following to the Web.config:

<system.web>
  <httpModules>
    <add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"/>
  </httpModules>
</system.web>

The entry above is for version 1.0. Make sure that the Version and PublickKeyToken attributes match the ASP.net Ajax version that you are using. Also you may want to disable event validation in your page:

enableEventValidation="false"

Hope it helps!

Solution 3

Are you using some kind of http module compression? It seems to cause problems very much like yours when using updatepanels. Please review this post.

If you are not ussing compression, maybe another httpmodule related error is making you suffer. Try adding this to your webpage:

enableEventValidation="false"

Maybe you could catch the exception with this kind of code:

 protected void ScriptManager1_AsyncPostBackError(object sender, AsyncPostBackErrorEventArgs e)
    {
        ScriptManager1.AsyncPostBackErrorMessage = e.Exception.Message+e.Exception.StackTrace ;
    }

<asp:ScriptManager ID="ScriptManager1" runat="server" 
            OnAsyncPostBackError="ScriptManager1_AsyncPostBackError">
</asp:ScriptManager> 

Source for that last thing.

Comments

[Ravi Gadag]

possible duplicate ?? stackoverflow.com/questions/290121/…

[Cade Roux]

@Ravi No, this is reproducible and consistent and none of those suggestions helped.

[Aristos]

Do you have clean the temporary files that asp.net creates ? at windows\microsoft.net\framework\version\temporary asp.net (to clear this the iis must be down)

[Cade Roux]

@Aristos Thanks, but that didn't help - same error in same spot (postback of some radio buttons in an updatepanel with exact same mangled response)

[sll]

Can you localize a problem and share an example application which able reproduce this issue? OffTop - UpdatePanels - evil, use true AJAX

[mattmanser]

You seem to want to solve this, here's probably how. If you don't have it, download fiddler from fiddler2.com, record the different web responses for the update request between your dev copy and a working server and then compare them to see what is different. It might then be obvious. If that doesn't work, I'd suggest posting the two raw responses here unless they're identical apart from the domain. The raw responses include the HTTP headers, these could be important so make sure they're included.

[Cade Roux]

@sll It originally seemed to be machine specific, but now another developer is getting it. It seems to be web host-specific in the sense that IIS Express doesn't have the problem.

[Cade Roux]

@mattmanser I have fiddler, perhaps the headers will show a difference indicating why the response is truncated.

[Mike Guthrie]

Do you have a server anywhere hosting IIS6 that you can deploy to? Since ASP.NET Dev Server is more similar to older IIS, and IIS Express is more similar to IIS 7, just trying to locate any more differences in your scenarios. Also, you have no tracing enabled in page or web.config, correct?

[Mikhail]

could you share the markup hosted/updated via UpdatePanel?

[Aristos]

The point of the error that you have place here is not help, is just the point that javascript report it back to you. Can you please show here the inside of the update panel ? And one more, can you remove temporary the updatepanel, and make some actions to see if you get aspx errors ?

[Aristos]

if the post is truncated, can you see if your viewstate is huge ? - and can not be hold by the cassini.

[saarp]

As one @mattmanser,@aristos stated, the information above is not sufficient to describe the error. You need something like fiddler or wireshark (I prefer wireshark) to see the raw HTTP traffic. My guess would be that you have your POST limit set too low and it is causing a parse error. Another possibility is that there is some poorly formatted HTML that is causing postbacks to fail.

[Cade Roux]

@Aristos This is the most likely, but I have not had time to verify. Unfortunately as with most things on this legacy application, we have lmiited time to refactor out the viewstate dependency and have tight deadlines for maintenance requests this last week.

[Cade Roux]

@Aristos go ahead and post this as an answer if you want the bounty - I'm still trying to confirm that this is the case and to find Cassini's limit. A viewstate tool I found for Firefox is not reporting the viewstate within frames, so I'm trying to ascertain that is what the problem is.

[Cade Roux]

The viewstate size is 8300 bytes on this particular page, but it's stopped giving the error, so I'm not sure what exactly it is sensitive to. In the past, it went away after some Windwos updates, so I assumed it was also some kind of framework sensitivity. I look forward to being rid of the viewstate as soon as I can in this legacy app.

[Aristos]

@CadeRoux 8k is big one. I have split my viewstate to parts under 1k. I like to tell you that there is also the possibility that is not this the error but a synchronization error with the data bind.