ASP.NET - how to fix Sys.WebForms.PageRequestManagerParserErrorException

Asked By anbu n on 31-Jan-11 11:45 PM
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 '<Html><Body><H1> Thi'.

Source File: http://www.binarch.info/Multiply/AiLink/ScriptResource.axd?
d=Mbf2IiVtPHHFHQLphpDlczI4pmeUzJVB114bpp-vHEbLZC38lCU5HlU4LM9REBqcFiBG0nX-BsEZhifqXT2AvdTorbGTQTL72asz-TMoI6RX2H3vxMdi9YzZFz0kzagE0&t=7f5e5dbc
Line: 1021
----------------------
the above error msg is displayed some times rarely.... but normally this error does n t show up.

how to fix this error or prevent this error
Vivek Jagga replied to anbu n on 31-Jan-11 11:51 PM
Hi,

Why do you keeping getting a PageRequestManagerParserErrorException?

Well, chances are you're doing one of the things mentioned in the error message. Here are the most common reasons and why they don't work:

  1. Calls to Response.Write():
    By calling Response.Write() directly you are bypassing the normal rendering mechanism of ASP.NET controls. The bits you write are going straight out to the client without further processing (well, mostly...). This means that UpdatePanel can't encode the data in its special format.
  2. Response filters:
    Similar to Response.Write(), response filters can change the rendering in such a way that the UpdatePanel won't know.
  3. HttpModules:
    Again, the same deal as Response.Write() and response filters.
  4. Server trace is enabled:
    If I were going to implement trace again, I'd do it differently. Trace is effectively written out using Response.Write(), and as such messes up the special format that we use for UpdatePanel.
  5. Calls to Server.Transfer():
    Unfortunately, there's no way to detect that Server.Transfer() was called. This means that UpdatePanel can't do anything intelligent when someone calls Server.Transfer(). The response sent back to the client is the HTML markup from the page to which you transferred. Since its HTML and not the special format, it can't be parsed, and you get the error.

How do you avoid getting a PageRequestManagerParserErrorException?

To start with, don't do anything from the preceding list! Here's a matching list of how to avoid a given error (when possible):

  1. Calls to Response.Write():
    Place an <asp:Label> or similar control on your page and set its Text property. The added benefit is that your pages will be valid HTML. When using Response.Write() you typically end up with pages that contain invalid markup.
  2. Response filters:
    The fix might just be to not use the filter. They're not used very often anyway. If possible, filter things at the control level and not at the response level.
  3. HttpModules:
    Same as response filters.
  4. Server trace is enabled:
    Use some other form of tracing, such as writing to a log file, the Windows event log, or a custom mechanism.
  5. Calls to Server.Transfer():
    I'm not really sure why people use Server.Transfer() at all. Perhaps it's a legacy thing from Classic ASP. I'd suggest using Response.Redirect() with query string parameters or cross-page posting.

Another way to avoid the parse error is to do a regular postback instead of an asynchronous postback. For example, if you have a button that absolutely must do a Server.Transfer(), make it do regular postbacks. There are a number of ways of doing this:

  1. The easiest is to simply place the button outside of any UpdatePanels. Unfortunately the layout of your page might not allow for this.
  2. Add a PostBackTrigger to your UpdatePanel that points at the button. This works great if the button is declared statically through markup on the page.
  3. Call ScriptManager.RegisterPostBackControl() and pass in the button in question. This is the best solution for controls that are added dynamically, such as those inside a repeating template.
Anoop S replied to anbu n on 01-Feb-11 12:40 AM
This error is caused due to the bug in the ASP.NET, you can avoid this by setting enableEventValidation="false" in the top of the webform.