I've a webservice which seems to works fine, but sometimes the webservice stop working for no apparent reason. When I check the response in Firebug I see an "empty" exception:
"There was an error processing the request"
When the error occurs none of the methods on the webservice is working - even the simplest methods which does nothing else but return some data from the database. What could cause a webservice to completly stop working?
Best regards,
Steffen
I'd same problems a few years ago. By using PerfMon I saw that I've to increase the usable memory for the hosting AppPool..
When you're logic is fine, it has to be a configuration problem on your webserver (IIS)
Related
I inherited an ASP.NET (.NET 4.7.2) application. It has Elastic rigged-up (via the Javascript API) to capture APM data and errors from the front-end.
The top offending errors in Elastic for months now have been:
Uncaught Sys.WebForms.PageRequestManagerTimeoutException: The server request timed out.
Uncaught Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 404 (but sometimes it will say 503).
Both refer to ScriptResource.axd as being the "culprit".
On the one hand, it sure would be nice if I could find out exactly WHAT resource or URL was being requested... as well as which page in my app is doing the requesting.... when such an error occurs.
But I'm at the point now where... as an alternative, I'd just be happy to change these from being unhandled exceptions to handled ones. (I don't think our users are actually having any serious issues from these. The major page for this app is one that updates a couple of key update panels once every 8 seconds. So, occasional failures of those requests are somewhat expected. Users would have already raised hell if something major was going on.)
I'd much rather see any errors in Elastic that are coming from our own Javascript code than from the Ajax Control Toolkit.
So, does anyone know how I might capture these?
I THINK I've finally found the right information (though some of these pages are from 2008). How to basically add a custom error handler to the Script Manager:
Script Manager 4.5 handling errors
https://social.msdn.microsoft.com/Forums/en-US/59a34e36-f80b-4344-a793-8ea2ce21abe2/ajax-exception-handling?forum=aspdotnetajax
Handle Asynch error messages with ScriptManager
https://blog.digitaltools.com/post/2010/02/03/Unhide-Exceptions-Hidden-By-AJAX.aspx
Looks like I should be able to either bury the exceptions... or get more details on them and pass them on through to get thrown to Elastic.
I think my biggest hurdle right now would be to actually try to recreate these errors myself (preferably in a non-prod environment). But I guess I'll figure that out somehow.
Thanks!
I have an ASP.NET application hosted in IIS calling Sharepoint using ClientContext. On a production deployment, a call to ExecuteQuery causes the ASP.NET to throw net::ERR_CONNECTION_RESET. On the server, the following exception was thrown:
at Microsoft.SharePoint.Client.ClientRequest.ProcessResponseStream(Stream responseStream)
at Microsoft.SharePoint.Client.ClientRequest.ProcessResponse()
at Microsoft.SharePoint.Client.ClientRequest.<ExecuteQueryToServerAsync>d__6.MoveNext()
Cannot complete this action. Please try again.
There is no other trace of any other error, except this.
I have tried setting TLS1.2 with no success.
I have also tried using a delay before the call to ExecuteQuery and the result was still a failure.
Can anyone suggest what could be going wrong here?
Note: it works perfectly on my local machine.
After spending a few valuable hours, I found the solution. One of the fields had a wrong date time value and Sharepoint, on the flip side, without throwing a meaningful exception, just caused the request in IIS to abruptly close.
Ok, so the background is this.
I have created a hardware controller for a fingerprint reader, and a web application that allows users that have scanned in to do things in the web application. The web application was created using Code First, and the communication is done through signalr 2.0 The problem that I am having is this. Everything works beautifully for about a day, this used to be about half a day, but in IIS 7.0 I changed the idle time on the application pool to 200 mins, but I am still getting an error at random times on the web server, I have managed to have extended the amount of time that is stays running. However, what confuses me, and why I cannot seem to get a handle on what is happening is that when it does go down;
A) I do not know why? (I am leaning towards a timeout somewhere)
B) The error message is the same one you get when you make a change to the database structure and forget to use Database-Update from the package manager console, Yet no one is changing the database.
c) If you leave it alone it will fix itself, and I do not know why or how.
Has anyone seen behavior like this? and if so what caused it and how did you fix it? Or can anyone offer how I can debug this?
Thanks so much for any help!
Kelso
If the exception is "The model backing the 'YourContext' context has changed since the database was created. Consider using Code First Migrations to update the database" you could try to catch that exception and log the content of the following method and compare it to the return value of the method in Application_Start or whenever it worked for you.
((System.Data.Entity.DbContext)(context)).InternalContext.QueryForModel(0)
The method gives you a XML representation of your database schema.
Just to update on this issue, it turns out that the IIS server had been set to only a single CPU and a single thread, (VMare setting) and that thread was getting hung, and could not create a new thread to continue processing, once we updated the cpu's and increased the thread count to 5, everything works like a dream.
I am having the same issue as described in this post, Diagnosing "Request timed out" HttpExceptions. I've turned on Failed Request Tracing as recommended and am working with someone at MS (although it's painfully slow).
The original post hasn't been updated in over a year, so I'm wondering if a fix was ever found or if you're just ignoring these errors.
Any help would be appreciated.
After over seven months of troubleshooting this issue, the fine folks at Microsoft finally tracked down the problem. It didn't end up being that complicated an issue, we all certainly learned a lot about IIS 7+ integrated mode.
In summary:
In IIS6 & IIS7+ Classic mode, the request doesn’t reach asp.net until the entire entity body is read. If the entity body doesn’t get completely read, asp.net has never been reached so http just logs the error and asp.net is never the wiser.
However, in IIS7+ Integrated mode, asp.net picks up the request immediately, so if the entity body doesn’t get completely read, asp.net logs the timeout and triggers the exception.
So, these exceptions can safely be ignored because they are expected behavior.
I really hope this helps someone else out there.
I am trying to publish asp.net mvc site on remote server I am getting the error as shown in figure. Any idea
I solved it the problem was that in the designer file connection name was different then that of web.config. Once both name are same it started running fine.
Any chance you could post a larger scale of the image, the stack trace is very tricky to read.
As a guess, it looks like the exception is being raised in the database context area of code - possibly Entity Framework??
First, have a look at the Models.EvloetDatabaseContext constructor - is there anything in there that might cause the null reference exception?
You could put some Trace.WriteLine calls in that method and use a tool such as DebugView to see how many of those messages are being sent out. I use his often when debugging issues on a client's server.