In a recent project we are currently getting 12031 errors. here is the complete error:
Sys.WebForms.PageRequestManagerServerErrorException 12031
the status code returned from the
server was 12031
The problem is, this doesn't happen all the time and we are unable to reproduce the error on development environment.
We use AJAX in our application and this exception happens on every page once in a while.
I've found a post on SO with the same problem and tried changing maxRequestLength to "1" to see if I constantly get the same error but I don't. Instead, I'm getting
Maximum request length exceeded.
So I'm starting to think that it is not related to maxRequestLength. I'm actually out of ideas. I have a ScriptManager in my MasterPage and its AsyncPostBackTimeout="240". That is the same amount of time (give or take). I get the 12031 error after 3,5 minutes of "nothing". I'm logging one of the pages and by logging, I mean logging every section of the page like "Page_Load is called" "xyz is called" etc and I have like 15 spots on the page for this. After user clicks a button and ScriptManager tries to do its job, no postback occurs, no logging happens. It is like the page wants to do a postback but too old to do it. Tries this for around 3,5 minutes and fails with the given error.
Please, if you have any ideas, HELP ME OUT .
Thank you
That error almost certainly has nothing to do with the size of the response, AsyncPostBackTimeout, or maxRequestLength.
Connection resets are usually indicative of poor network connectivity or a server loaded down to its capacity limits. A few things you could try:
Inspect the Windows Event Log during the time(s) that the kiosks were known to have received the error. Look for any relevant errors or warnings.
If feasible, ask the kiosk staff to use something like Pingtest to test the quality of their local network connection at the time that they receive the error in your app.
Use a service like Pingdom to ensure that the server itself isn't intermittently losing connectivity.
This error may be due to the HTTP Runtime limitation of the maxRequestLength. The default value is 4096.
Try adding (or editing) the following entry in your Web.Config:
"<httpRuntime maxRequestLength="8192" />" (effectively allowing 8mb of data transmission, instead of the default 4mb).
Please not....You can set data as per you max request. 8192 is not the limit. Also you need to add Page.Form.Attributes.Add("enctype", "multipart/form-data"); in Page_Load event of the page.
You'll want to enter this in the System.Web configuration section.
How do I 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):
Calls to Response.Write():
Place an 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.
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.
HttpModules:Same as response filters.
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.
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:
The easiest is to simply place the button outside of any UpdatePanels. Unfortunately the layout of your page might not allow for this.
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.
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.
Good luck!
I have received this error before when we had a Barracuda Device sitting in front of our website. It was a maximum request length issue because Barracuda protects against overloading the request size. We removed the device temporarily and it solved the problem. Not sure if this is your problem.
Related
I've got a site that uses an order entry form and sends a rather decently sized POST request when the form is submitted.
However, when a particular value is passed in one of our form variables (OrderDetail), every time without fail, it gets an error page in the browser and a 504 error via Fiddler.
Here are a couple examples of tests I ran last night sending POST requests through Fiddler. When the "OrderDetail=" value is changed to the below it will either submit successfully or return a 504 error after a few seconds:
These ones FAIL:
&OrderDetail=Deliver+Writ+of+Execution%3B+and+Application+for+Earnings+Withholding+Order+to+Los+Angeles+County+Sheriff+DASH+Court+Services+Division+per+instructions
&OrderDetail=Deliver+Execution+Earnings+Withholding+Order+to+Los+Angeles+County+Sheriff+DASH+Court+Services+Division+per+instructions
&OrderDetail=Deliver+Writ+of+Execution%3B+and+Application+for+Earnings+Withholding+Order+to+Los+Angeles+County+Sheriff
&OrderDetail=Deliver+Writ+of+Execution%3B+Application+for+Earnings+Withholding+Order+to+Los+Angeles+County+Sheriff
&OrderDetail=Writ+of+Withholding+Execution+Order+Los+Angeles+County+Sheriff
&OrderDetail=writ+Execution+adsfsdfsdfsd+Order+County
&OrderDetail=wd+Execution+adsfsdfsdfsd+Order+Count
This got me thinking that perhaps it has to do with the words "Exec" ('Exec' and 'Execution' throw errors, 'Exe' does not) and "Count" ('County' and 'Count' throw errors, 'Cont' does not)
However, I haven't seen anything this specific mentioned in google searches regarding the 504 error.
Regarding the Coldfusion code around this, there is nothing fancy for this page. Just a standard form post. I added a cfmail test in the Application file and on these failures it is never ran, so this seems to be between the browser and IIS. We're on a shared server, so I can't see too much there, though.
Oddly enough, when the &OrderDetail= param is changed to one of these values (very similar to the above), the result is success:
&OrderDetail=wd+Execution+adsfsdfsdfsd+Order+Coun
&OrderDetail=wd+Execution+adsfsdfsdfsd+Order+Conty
&OrderDetail=Writ+of+Withholding+Order+Execution+Los+Angeles+County+Sheriff
&OrderDetail=Writ+of+Withholding+ExecutionOrder+Los+Angeles+County+Sheriff
In the 3rd one, I put 'Order' BEFORE 'Execution' and it works..
The total length of this POST request is about 4720 characters. I've increased the length of this one field to 5-6 times its length and they passed, so it almost seems tied to the value of the "&OrderDetail" param in the POST.
Any ideas on why this specific data could be an issue for a web server? I've never seen this before and it doesn't continue to be a problem for nearly any other request going through.
One interesting note as well: In the POST request, this variable is pretty close to the start of the param list. If I delete everything after it, it goes with no problem. Although I haven't been able to nail down what in the subsequent lines could be causing it. I can post the entire request if it will help.
More importantly though, I just want to know what could qualify as "reserved" or "illegal" for FORM data. Everything appears to be escaped properly so I'm not sure what else can be done here except for some pre-processing javascript to further escape any such words.
Thanks!
Given that EXEC and COUNT are causing the error, whilst putting ORDER before EXEC is preventing the error, this sounds like something is making a flawed attempt at protecting from SQL injection attacks.
If you have any software in place that claims to do that, I would see if (temporarily) disabling it stops the problem from occurring.
(This software might be at the firewall level, so you may need to talk to your sys admins.)
Importantly, I would also check your codebase for where OrderDetail is used, and make sure that it is using cfqueryparam whenever it is used inside a query - and the same goes for all other user-supplied data.
I have a strange problem:
I have a site which has an administration system.
In the system there is a way to edit my inputs. To make this easier, I can search for their ids to find them.
The problem is when the page posts back the session variable I hold the "logged in" value in, becomes nothing.. and i get kicked out. Why is that happening? Session variables should hold at least 20 minutes if anything else is stated?
EDIT: It works for a coworker, but not for me.. Also, it only does it on certain inputs.
EDIT2: Turns out i get an exception. but it doesnt say what, only says "property evaluation failed". i get it on this code row:
Response.Redirect("./admin.aspx?search=" + u.FirstOrDefault.ProductID.ToString, False)
And sience it goes through this statement, its not because it is an objectreference not set to an instance of an object
If u.Any Then
If you experience an exception your session might be restarted.
Create a global.asax and set breakpoints to the Application_Error, Session_End and Session_Start events to track down the issue
Edit based on your update:
Make sure that u.Count == 1, because FirstOrDefault will throw an exception, if the count is > 1.
Have a look at this link http://support.microsoft.com/kb/312629/EN-US/ which should cover your original problem
http://forums.asp.net/t/1296202.aspx/1
If you have Web Garden enabled (multiple worker processes for an application pool) this can explain such behavior - been there.
Either have one worker process for the pool, or switch to Database driven Session.
Do you have cookies enabled? If not, this would explain this behavior. Especially as you state it works for the co-worker, you can deduce it's a client-side issue.
I have a ASPX page which queries from a database. Once we have the dataset it is bound to a gridview and displayed on the page. All this happens in the Page_Load event.
Ofcourse this a simplistic approach. What is the best way to inform the user that data is being retrieved and when we have the data to update the page with the results in the dataset.
I want all this to happen within the same ASPX page and do not want to hop around pages to achieve this. I looked at update panels however it wasn't clear to me how this could be done with an update panel without having a control which triggers the update for the update panel. There are no controls on my page whhich initiate the database query, it occurs as the page is loaded.
If I do the query in a worker thread and then call the Update method on a UpdatePanel with the gridview as part of it, it doesn't work. Nothing happens.
Any thoughts or help? Thanks.
Well, this is a good question. Personally I have two pretty similar methods to do this:
Have a java script that will make an UpdatePanel reload with a short interval. This will create a series of post-backs to the server. During each post-back you should chek you worker thread and return immediately with the state report, usually one of error, pending, success + data
With a java script, make an asynchronous request to a web-service that will block until the data is fetched. This method brings no latency as compared to the previous one (the time between polls), but may suffer from some browsers/servers attitude to hanging open connections. This is normally solved by some interval (say, 1 minute) introduced, so that the hanging request will return with a message like need more time, in which case the java script should simply repeat the request.
I have a page where I am pulling a dataset from the database, a few thousand records. I get it when the page is loaded and store it in the cache. Each time an operation is performed on the page, I check the cache to see if its still there, and if not, go get it again (20 minute expiration); fairly typical setup.
When I run the page, the initial data loads fine, and a default RowFilter is applied to the data. When I change the value of a dropdown (which changes the RowFilter), the page hangs for a moment, then returns a javascript error:
Line: 80772370 (yes, thats line 80 million...)
Char: 17
Error: Syntax error
Code: 0
URL: -the url of the page I'm on-
This error is repeated EXACTLY 20 times.
When I re-run the page and the operation that renders that error, I get a different line number (for example, the next time I ran it after I posted the above message, the line is at 80718666), exactly 20 times again.
Now a few curveballs:
I was having the exact same issues when I was using the Session to store the data rather than the cache.
I do not have this problem in the development environment (this is happening in QA). The web.config for each environment are nearly identical, but the primary difference between them is that QA uses a sessionState server that is separate from itself. This is why I moved from Session variables to the cache in the first place.
When the search criteria is intended to return no results at all, it performs as it should (shows no results).
Now this hasn't exactly been my best week, so maybe I'm missing something big, but I could use some guidance.
Thanks SO community.
if you use UpdatePanel, remove it to see what's the real error is because now the error is hidden on a javascript return string, in the position you mention.
After you find your error, bring up again the UpdatePanel.
I can assume that the error is a null object/control that have been cached, and you forget to check if it not null.
When you cache parts on your page, and controls, then you need to check them on your back code, if they are null before use them.
I've made some performance improvements to my application's backend, and to show the benefit to the end users of the GUI, we've been using the Trace.axd page to take timings. (The frontend is .Net 1.1 and the backend is Java, connected via Web services.)
However, these timings show no difference between the old and the new backends.
By putting a breakpoint in the backend and holding a request there for 30 seconds, I can see from Trace.axd that the POST is taking 3ms, and the GET is taking 4s. I'm missing about 26s...
The POST is where the performance improvement should be, but the timing on the Trace page seems to only include the time it takes to send the request, not the time it takes to return.
Is there a way to inrease the granularity of the information in the trace to include the whole of the request? Or is there another way to take the measurements I need?
OK, I kind of got what I wanted in the end. The problem is the IIS Trace doesn't include the time the POST takes to return.
I found that I could use Trace.Write() to add custom entries to the trace log, and even add a category, using Trace.Write(string category, string message).
Adding a call to Trace.Write() in my code that executes after the POST has completed gives me a better figure.
Still, it's not ideal as it's custom, and it's down to me to put it as near to the end of the POST cycle as possible.
I'm not sure how you're making the requests on the .NET side, but I'll assume that there's a HttpWebRequest involved somewhere. I'd expect HttpWebRequest.GetResponse() to return as soon as it has received the response headers. That way, you can start processing the start of a large response while the rest is still downloading. If your trace messages are immediately before and after a call to GetResponse, you therefore wouldn't see the whole execution time of the backend. Can you add a trace message immediately after you close the response?
It is abnormal that the trace output doesn't show all the time you've spent in the brakpoint. Did you check the total time column to see if it matches the time you've spent in the request ? Don't forget that one of the columns only shows the time spent since the preceeding trace statement.
If you want more granular data in the trace output, you can add your own. The TraceContext class has two methods, Warn and Write that add lines to the output (warn adds it in red).
The TraceContext is accessible from every page or control: just use this.Trace.Warn() or this.Trace.Write() (and I think it is also accessible through the HttpContext class).