I have a rather complex legacy ASP.Net application that is under continuous development, and for one client it has started erroring recently.
The application uses ASP.Net 3.5 and C# on the server side, backed by SQL Server 2005 and IIS6.
The application also utilises the Microsoft ASP.net AJAX libraries and DevExpress components.
We have a fairly comprehensive logging platform in place, via a Page_Error handler in a custom page base, which logs all unhandled exceptions and displays a nice error page.
The problem is, one client has recently started getting errors which we cannot trace - nothing is logged, despite the nice error page being displayed. No exceptions are caught and handled by the Page_Error handler, which is the method which redirects users to the error page - and no redirection happens without the error being handled.
I have added some client side Javascript to the ASP.Net Ajax PageScriptManager EndRequestHandler Javascript handler which logs clientside errors to a wide open ashx logging script.
The only errors the client side catches are as follows:
Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 0
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'.
These errors have no corresponding server side error.
Unfortunately, there is no scope to set up unit tests for this project, its too large and I wouldn't know where to begin for the client-server interaction part.
My question is, can anyone recommend a method of seeing what is erroring, why it is erroring and why this isn't being caught by the Page_Error handler?
You could try using ELMAH to catch exceptions that aren't handled inside your application.
As it turned out, there isnt a way to track these down - the issue was wider in scope and involved a clients firewall preventing AJAX communications randomly, or modifying the resulting pass back.
Related
I use an Application_Error handler to log all unhandled exceptions; generally it works well, but 404 errors always are skipped. Any ideas what might be the reason?
Actually, that is because that's an http protocol error returned by your web server. It's not a .net framework exception and thus it can't be handled by asp.net. However, you can configure IIS to serve a custom page when it returns a 404 error and this can be done through your web.config file. Needless to say that this custom page could be an aspx page where you can add some custom processing such as logging the error ;)
404's are not always caused by exceptions. You can just set the Response.Status* fields to generate a 404 response.
Use Application_EndRequest to examine the response and act on it.
Here's the situation: -
I have
<customErrors mode="On" defaultRedirect="error.html" />
in my web.config.
I also have custom error handling code in Application_Error (in global.asax.cs) that checks for certain well known exception types and redirects to custom error pages for each. If the exception is not a well known type then I simple return from Application_Error without calling Server.ClearError() so the default custom handling should take care of showing the page error.html.
But whenever my app throws up an unhandled (and not well known) exception I end up at the default Asp.Net error page - you know the one I mean, the yellow screen of death...
Runtime Error
Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed.
Details: To enable the details of this specific error message to be viewable on the local server machine, please create a tag within a "web.config" configuration file located in the root directory of the current web application. This tag should then have its "mode" attribute set to "RemoteOnly". To enable the details to be viewable on remote machines, please set "mode" to "Off".
I have checked the obvious stuff (like double checking that I am not throwing another error in Application_Error and I am not accidently' calling ClearError. It is definitely something fishy with this one web app (I made a little test web app and the custom error handling worked as expected) - that should rule out oddities in my machine.config file.
I am going to keep on scratching my head and trying things but in the meantime I thought I would put the question out here to see if anyone had any bright ideas.
PS. I am working on Windows 7 Business (IIS 7.5) but the same behavior is observed on Win server 2003 (IIS6).
Thanks Joe and Click for having a look but this problem is all my fault!
One crucial bit of information that I omitted from the description is that my web page flushes the response before the request is finished (see * below if you want to know why I do this nastiness).
It seems that once some content has been sent to the client, the customError handling no longer works. I can't say that this is a failing of the custom error handling because it would probably take some dark voodoo to tell a browser to redirect to once it had started rendering content!
Having said that I was hopeful that adding redirectMode="ResponseRewrite" to the customError node would help (maybe get the error page below the content I have already sent to the browser?) but that fails too. Nevermind.
A quick google yields this http://forums.iis.net/p/993221/1313916.aspx - and a chap on there has a work around that I will try. The technique suggested in http://forums.iis.net/p/993221/1399583.aspx#1399583 works. It is far from ideal (we have to read the web config) but it works.
(*) why am I flushing the response before the request is finished? Some of our pages return large reports which can take several seconds to generate. We send a "PLease wait + spinny gif" message to the clients at the start of these requests and flush that so that the browser renders the message + icon whilst it waits for the rest of the response. I think I shall investigate a less "hacky" way of achieving this.
when ASP.NET throws an application error, IIS shows the 500 HTML error, but when a WCF service throws a FaultException (IIS 500), the client gets a proper SOAP fault with error message in it.
Is there any good documentation on this request processing?
This behavior is exactly how SOAP faults works.
Whenever the code within a Web service raises an exception, ASP.NET catches that exception >and transforms it into a SOAP Fault.
See this link for details
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 PUB'.
There are tons of references for this error message on the Web, but I can't figure it out. The problem is that the application works fine when I run it locally or when deployed to other servers. There is just one server where I get this error during a post back from an Update panel (it is supposed to populate and open a popup panel). There is no Response.Write() anywhere in the code and the other suggestions do not apply, either. I think. The next thing I will try is install the remote debugger. In the meantime, can someone tell me how to check if server trace is enabled (IIS 6)?
Oddly enough, this was caused by a database exception. The application framework injected the stack trace into the HTML stream, but obviously in case of an Ajax call the error should not be reported in the HTML response.
I have two ASP.NET projects in my solution, and run on different localhost ports when I start debugging. I have a generic handler in site A, which is called by site B:
String url = "http://localhost:1234/UrlOnSiteA.ashx";
WebClient client = New WebClient();
client.Credentials = CredentialCache.DefaultNetworkCredentials;
client.OpenRead(url);
The OpenRead call throws an exception with a 500 error, and I don't know why. The error message is:
System.Net.WebException: The remote server returned an error: (500) Internal Server Error.
Other info:
A breakpoint on the very first line of the handler code isn't hit.
The handler runs properly (and hits the breakpoint) when its URL is used in a browser.
Visual Studio 2008 Professional, running .NET 2.0 sites.
I suspect it's a configuration issue. Any ideas?
I'd diagnose this first by figuring out what's causing the exception. Look at the Response property of the WebException, and read the HTML returned. Any clues? (You may need to disable custom errors in your web.config to see the actual error response.)
Another approach to get the same response info would be to use Fiddler, and set the proxy of your WebClient call to the Fiddler proxy address. Then you can use fiddler to see the response HTML.
A slightly different approach would be to change the Exceptions settings in Visual Studio to break into the debugger whenever a WebException is thrown. You can do this from the Debug...Exceptions... dialog box.