Tracking Down Mysterious Errors_问答_开发者_运维开发者技术经验分享

开发者 https://www.devze.com 2023-01-24 23:17 出处：网络

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, whi开发者_运维技巧ch 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.