ASP.NET Ajax Error: Sys.WebForms.PageRequestManagerParserErrorException

L

15

26

My website has been giving me intermittent errors when trying to perform any Ajax activities. The message I get is

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 '

<!DOCTYPE html P'.

So its obviously some sort of server timeout or the server's just returning back mangled garbage. This generally, unfortunately not always, happe

Lew answered 14/11, 2008 at 13:45 Comment(3)

@Phil - I notice you marked splattne's answer correct, yet you said in a comment underneath that none of them applied. I am having the same problem, and none of the "reasons" apply for me either. What was the solution you finally found? – Curium 31/8, 2009 at 19:34

@Curium -- sorry I got laid off from that job back in February and can't actually remember what we did. Sorry I missed your comment for so long. – Lew 18/9, 2009 at 12:58

niharstechnicalfunda.blogspot.in/2012/03/… – Standardize 31/8, 2012 at 11:58

P

24

There is an excellent blog entry by Eilon Lipton. It contains of lot of tips on how to avoid this error:

Sys.WebForms.PageRequestManagerParserErrorException - what it is and how to avoid it

Read the comments too. There is a comment of somebody with the same problem: "I solved it changing server idle time of my app pool on IIS. It was only 5, so I incremented it and now works."

"The UpdatePanel control uses asynchronous postbacks to control which parts of the page get rendered. It does this using a whole bunch of JavaScript on the client and a whole bunch of C# on the server.

Asynchronous postbacks are exactly the same as regular postbacks except for one important thing: the rendering. Asynchronous postbacks go through the same life cycles events as regular pages (this is a question I get asked often).

Only at the render phase do things get different. We capture the rendering of only the UpdatePanels that we care about and send it down to the client using a special format. In addition, we send out some other pieces of information, such as the page title, hidden form values, the form action URL, and lists of scripts."

Most common reasons for that error:

Calls to Response.Write():
Response filters
HttpModules
Server trace is enabled
Calls to Server.Transfer()

Phile answered 14/11, 2008 at 13:50 Comment(3)

I read the article -- none of these apply. The bug might actually be the update panel in the master page. Thanks! – Lew 14/11, 2008 at 14:29

A user of our software is seeing a very similar error. I'm wondering if a solution to this problem was ever found? – Ewold 9/2, 2009 at 6:9

I would add a comment to the question. So the user will be prompted the next time he logs in. – Phile 9/2, 2009 at 7:32

O

10

Probably there is an error occuring on post back. In this case, you can view the details about the error by adding a PostBackTrigger to your updatepanel and referencing the button which causes the problem:

    <asp:updatepanel ID="updatepanel1" runat="server">
        <Triggers>
            <asp:PostBackTrigger ControlID="button1" /> 
        </Triggers>
        <ContentTemplate>

        </ContentTemplate>
    </asp:updatepanel>

Oloroso answered 19/7, 2011 at 13:14 Comment(1)

Very thanks. I tried for 1 full day but your answer helped me alot :) – Monovalent 29/5, 2015 at 10:56

R

4

I had this happen to me and none of the causes on the list in the answer applied. I didn't find the root of the problem until I disabled my AJAX altogether. Discovered that the code was saving an object to the ViewState that contained an unserializable object. I made the object serializable and it started working again.

Reactive answered 9/3, 2012 at 22:54 Comment(0)

S

2

Problem: Sys.WebForms.PageRequestManagerParserErrorException will occur when redirecting your page, lets say button click inside UpdatePanel in aspxAjax.

SOlution:

Add a "GoTo" button in your aspx page where update panel is using and add it outside Update panel
In your code assign ur just registered userID to session variable , say Session["UseridJustregistered"]=Id from DB or UsernameField
Respose.Redirect("regSucces.aspx?urlid='" + Session["UseridJustregistered"] + "'");
Check if Session["UseridJustregistered"] is null or not

This is OLD Classic ASP way which can solve our problem , by the time Microsoft find a solution we can tackle it this way.

Syllogism answered 4/8, 2010 at 8:48 Comment(0)

E

1

I solved this exact same problem removing the Content-Type: form the Custom HTTP Headers section in the HTTP Headers tab in IIS. This was breaking the encoding of the page and somehow it affected Ajax in general.

The Content-Type I had configured in IIS was setting the encoding to ISO-8859-1.

Emeritaemeritus answered 9/2, 2010 at 19:27 Comment(0)

D

1

This may be a little hacky, but it solved the issue for me. I didn't have any of the common reasons for the error, so I just put in this band-aid in the page load:

if (Session.SessionID == "")
{
    Page.Session.Add("SessionID", Session.SessionID);
}

Douse answered 21/5, 2010 at 17:17 Comment(0)

S

1

I solved this same problem by removing mistakenly-nested UpdatePanels.

Solarism answered 23/12, 2011 at 16:35 Comment(0)

I

1

I finally solved my variant of this same problem. I was attempting to copy/move a selected value between 2 listboxes in a webform. In my case, I had to specifically call {listbox}.ClearSelection() prior performing the action the 2nd time around.

So obviously this problem/error message can occur for a multitude of reasons.

Interposition answered 31/7, 2012 at 22:14 Comment(0)

G

1

Change of the app pool FROM INTEGRATED to asp.net classic solved the problem for me.

Georgiegeorgina answered 19/8, 2012 at 10:42 Comment(0)

N

1

In our case the issue was caused by a rewriting proxy on the way. The rewrite modified the content of the update panel response. But this response also contains original size. The rewriting mechanism cannot know that few bytes of the response actually contains original response size and it should also be modified.

The update panel response starts like this:

1|#||4|30502|updatePanel|pnlUpdate| ...

The 30502 is original size of the content which is being updated. Rewriting engine modifies the output, but the size stays unchanged => parser error exception.

I don't see a way how to overcome this issue from the client side. We would need to know how exactly was the content modified and then somehow change the size in the response before UpdatePanel ClientScript starts processing it.

Nudity answered 28/5, 2015 at 18:53 Comment(4)

Hello mirva! Did you find a solution for your problem? – Masha 19/6, 2015 at 6:46

Hi Franki. Unfortunately not. We reported the issue back to the vendor of the proxy, but I'm unaware of any resolution. – Nudity 25/6, 2015 at 11:15

Thanks for the reply. I had to replace every updatepanel with a devexpress callbackpanel. – Masha 25/6, 2015 at 15:10

Same for me. Thank you for this tips! I think I have to adapt to it and try to replace exactly the same length instead. It is ugly but no better easy way. – Cumings 11/3, 2021 at 23:57

P

0

I also got this error. The solution reported by "user1097991" solved it for a while (I was using not-serialized objects on viewstate)

But later the error returned again, now in a random fashion. After some search I got the answer: the viewstate was becoming too large and was been truncated. I disable some viewstates on grids and menus and the problem haven't shown again.

Perspiration answered 19/9, 2012 at 0:55 Comment(0)

V

0

I found that my issue was related to a nul character being rendered in the databinding of a GridView. The expected length of the response wasn't matching the actual length of the response text which resulted in the error being thrown. Once I fixed the data in the database, I no longer got the error. The ultimate fix will be to sanitize the text getting rendered during the RowDataBound event.

Looking through the database, I couldn't see the bad data since SQL Server 2008 doesn't show the text if the nul character (Char(0)) is in the string. In the RowDataBound event of my GridView, I added code to throw an exception for any text that had special characters in it. This is how I found the record that contained the nul characters.

tl;dr - Check for nul characters in the rendered html.

Veneering answered 14/11, 2012 at 16:1 Comment(0)

C

0

Please also be aware that this can be caused by not properly html encoding what you may be rendering to the page through partial postbacks.

Cilurzo answered 19/12, 2012 at 21:29 Comment(0)

G

0

I had exactly the same error.

For me it was

<add name="ScriptModule" type="System.Web.Handlers.ScriptModule, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>

Missing in the httpModules section of web.config (.Net 3.5 app)

This error seems to may be related to many various things.

Gallaway answered 14/4, 2015 at 13:45 Comment(2)

what section of the web.config? – Jerrome 28/3, 2016 at 21:6

Hello. Like I said it's <httpModules>. – Gallaway 29/3, 2016 at 11:24

U

0

Update the ScriptMode to "Release"

<asp:ScriptManager ID="ScriptManager" runat="server" ScriptMode="Release"></asp:ScriptManager>

Unique answered 14/7, 2020 at 10:18 Comment(0)

Recommended topics

Hot tags