PageRequestManagerServerErrorException Error stops all partial post backs on page

I am having an issue with my application. The web application is quite large and works by using a number of ascx and VB server controls, each of which does various partial post backs using update panels. Everything works fine on my local machine but when I push my application to the server (IIS) I notice that my application will throw an error during an update of an update panel. This error is intermittent but will occur, eventually, if I use enough of the controls on my page that causes partial postbacks. Here is the error:

Code:

---

Sys.WebForms.PageRequestManagerServerErrorException: Object reference not set to an instance of an object.

---

I'm not sure what is causing this error or how to track down which control is causing this problem. I've tried debugging the live application using IE's Developer Tools. The error seems to be originating from a web resource, MicrosoftAjaxWebForms.debug.js. The function that is having the problem is:

Code:

---

_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;
    }
},

---

The data variable is coming across as null. Anyone know how to address this problem or how to find out specifically which control on my page is causing the issue?

This causes the above error and, worst, stops all updatepanels's partial postbacks from working until the page is refreshed. I an able to trap the error like this:

On the page with the scriptmanager (its a master page):

Code:

---

Protected Sub ScriptManager1_OnAsyncPostBackErro(ByVal sender As Object, ByVal e As AsyncPostBackErrorEventArgs) Handles ScriptManager1.AsyncPostBackError
    ScriptManager1.AsyncPostBackErrorMessage = e.Exception.Message
End Sub

---

In it javacript:

Code:

---

    function pageLoad() {
        Sys.WebForms.PageRequestManager.getInstance().add_endRequest(onEndRequest);
    }

    function onEndRequest(sender, args) {
        if (args.get_error() != undefined) {
            var msg = args.get_error().message;
            var sen = sender.id;

            alert(msg + ' Sender: ' + sen);
            args.set_errorHandled(true);
        }
    }

---

But the error still stops all update panels on my page from working. Does anyone have any insight or suggestions?

Thanks
jason

I'll have a stab in the dark because I don't have experience with update panels in production. If you know better my bad...

1st guess - the site has been running for some time and the error as you say appears intermittent
2nd guess - doesn't happen with all browser versions and/or there is a later version of asp.net ajax.js files

I don't want to give you the run around but from the client side "sound" of the error I'd be checking known issues with browsers/asp-ajax.js files

Quote:

---

Sys.WebForms.PageRequestManagerServerErrorException: Object reference not set to an instance of an object.

---

Is not a client-site error... that's a server-side error... your js code is a red herring. I know this is going to be a pain, but you need to debug from the server side, figure out which server component is throwing the exception and then take a look at how to resolve it. Is that ALL you get in the error message? With luck you can narrow it down to a specific control TYPE, (it probably won't be the updatePanel itself, but one of the child controls on it) and even better the location where the error actually happens is something in your control (and not tucked away else where.)

Even though it may seem intermittently happening, but do try to document and track when it happens, a pattern may appear.

-tg

Thanks for the response techgnome,
As you stated, the error was being thrown by a component within an update panel (took about 4 hours to find). I have fixed the error but I am a bit lost as to how to handle things like this in the future. Specifically, I certainly do not want the ajax control toolkit to stop working in the event one component has an error, especially if it is an exception I created and I am throwing. Any suggestions on how to handle an AsyncPostBackError without bombing my entire application? As you can see in the above code, I am able to trap the error. Is there a way to prevent this, without refreshing the entire page?

Thanks for your help!

jason

No clue to be honest... that's something that is waaaay oustide my circle of knowledge or experience. There are others around here that are far more knowledgeable about such things than I.

-tg

Best bet is to handle it inside the global.asax. I wide range of uncaught will go in there. Not sure about Ajax though. It's some server side some client side, maybe you can get the exception maybe you can't but since this seems as techgnome said, a server side issue then i guess global.asax will grab it. If you can reproduce the error and you see that it's going in global.asax then it's fine. Problem is when you have client side exceptions. There i am a little blur myself. I mean you can use JS try catch but again i don't know the ajax behavior and most of the controls are stand alone and you can't or will have a very hard time using JS on them. If you cannot pinpoint an exception you will have to see your server error logs, at least for server side problems.

The error you describe happens (sometimes!) if you use an ImageButton to do a postback within an Update Panel. A common solution is to change ImageButtons to LinkButtons.

I've just had a similar problem. I had two controls in the header row of a gridview. The data populating the gridview was empty. I had forgotten to check if the references to the controls in the header row were null, and, all the users saw was a page that stopped working. Nothing (obviously) showed up in de-bugging.

I find (sometimes!) if you have, for example, a gridview inside an update panel and you allow things like filtering the data to show a subset of the data i.e. the update panel has already done a postback and has been repopulated - things you click on within the update panel suddenly don't postback.

I'm tending to add these controls as triggers for the UpdatePanel - even though they are children and ChildrenAsTriggers is true.

Have to say, never had these problems in Framework 2.0. Only since moving to 4.0 have they manifested themselves. The problem and solution, no doubt, is probably buried deep within the ScriptResource files.

well, as it turns out the problem was due to an error in my server code. I was overdoing it with sessions, which would cause the app pool to be reset. This, in turn, would cause my code to fail. I was able to handle the error so it wouldn't cause this problem but I was hoping there would be a way to prevent future errors from causing all my ajax and javascript from failing. Thanks for everyone's responses!

Quote:

---

Originally Posted by jasonwucinski

well, as it turns out the problem was due to an error in my server code. I was overdoing it with sessions, which would cause the app pool to be reset. This, in turn, would cause my code to fail. I was able to handle the error so it wouldn't cause this problem but I was hoping there would be a way to prevent future errors from causing all my ajax and javascript from failing. Thanks for everyone's responses!

---

I am intrigued. I use Session a lot. What is the scope of your application? Mine is an intranet - up to a thousand users - probably 20 session variables set per user.

This was actually a good "lessons Learned" for me. A little background on the application and the problem I was seeing. I decided I wanted to create an application that would use update panels as much as possible, to create a nice flowing application. In this way, I wanted to create an experience for the user that would make them think everything was synchronous had had no post backs or page transfers. The application was for our company and was also running on a local Intranet.

To help do this, i broke out each component of my application and created its own server control. For example, I had a group of controls added to one single user control (ASCX) that consisted of a modal dialog with gridviews, buttons, etc on it. To keep track of all the data coming and going, each control kept track of it's own data in session. For the most part, this data in the sessions were lists of objects. As the application grew (that is to say, as the user used the application, the sessions would grow) I would get intermittent errors. These errors only occurred when I pushed it out to our server but ran fine locally in debug and on my local IIS server. The error took me a few days to track down but ended up being an object would that was being kept in session would sporadically get "lost".

As it turned out, our IIS had a cap on in memory size. Once that cap was reached, IIS's App Pool would be restarted, causing all session to be reset. This did not occur locally because I had to cap. So, I had to re-think how data was being persisted. I ended up using view states for most of my data (which requires that the classes be serialized). I did have a control that could not use view states and had to rely on sessions. For this one, I made sure i added a method that could be called to clear out all session data when it was no longer needed.

In the future, I think I will do a few things differently. First, be more judicious with my use of Sessions. I'm not sure if there are any limitations on view states, but I have not yet experiences any issues. I also think I will stay away from update panels (the ajax control loolkit all together) and rely on regular ajax. Second, while update panels make for fast development the cost is heavier partial postbacks.

jason

There is no limit on viewstate as it's held on the page in a hidden field and posted to the server, if you view source you will see it above the html. You only need to be cautious of causing "bloat" if it gets really large then it can slow down the time it takes to transfer this back and forth. For intranet this may not be a problem but worth keeping an eye on. The general rule is if viewstate is not needed turn it off to create leaner pages.