Does this ever happen to you?
You are sitting at your development machine and you are made aware of an unhandled exception in a deployed asp.net application. You visit the deployed web app. You can't see the exception detail in your browser, because custom errors is set to remote only. So you have to login to the web server and instigate the exception.
Is there a built in way to turn custom errors off for certain remote clients?
This only happens to me for trivial applications where I haven't implemented a better solution, like ELMAH. But, it's still annoying when it happens.
2 things. One, if you dont have a sophisticated Exception\Logging Policy already implemented, check out the Microsoft Patterns and Practices Enterprise Library - http://entlib.codeplex.com/ - this may be helpful in tracking down bugs in your software.
Secondly, at the very least, put some logging in your global.asax code behind's Application_Error event, you can capture the last unhandled exception by using something like:
Dim lastError As Exception = Server.GetLastError.GetBaseException
Then you can add custom error pages to your web.config and not worry about debugging from a yellow screen, but still capture any error details.
HTH
You can use remote debugging.
This MSDN Article discusses debugging strategies for ASP.NET. If you scroll down to the "Local and Remote Debugging" heading there's some information for you and a link to the remote debugging article.
Basically you can debug a remote server in visual studio. Not reccomended for production servers, but staging servers for sure.
Related
I read the Global Error Handling recommendations and the Tracing in Web API 2 articles, and I understand how to set these things up. However, I noticed in the error handling part, that it states:
While Web API does have tracing infrastructure that captures error conditions the tracing infrastructure is for diagnostics purposes and is not designed or suited for running in production environments. Global exception handling and logging should be services that can run during production and be plugged into existing monitoring solutions
I'm looking for clarification on this. Is this statement saying that errors should only be logged as part of the trace when not in production, or that a custom implementation of ITraceWriter should only be registered with the HttpConfiguration when not in production?
I would assume that the article says
not designed or suited for running in production environments
simply for the performance impact, but is there some different contextual info that I could see for a specific error by looking at the Exception on the TraceRecord vs. the Exception that gets passed into the IExceptionLogger?
Going by what was written, it's meant as a rudimentary form of tracing and logging that whilst fine for developer and diagnostic environments is not for production due to performance and feature reasons.
To be due-diligent it advises to use an out-of-process service (eg log4net in a separate process or take your pick from Azure) so as to reduce probability of logging failing due to a fault in the core process; room to expand performance; and potential for a more feature rich logging system not provided in the default design.
I am using .Net 2.0 and my site seems to reach the deadlock state at certain period. It stops working until I recycle the application pool or change something in web.config file. I think deadlock is causing this issue.
I am wondering if there is any tool to debug/check the site to find the code that could be causing the deadlock.
Right now I had to set recycling interval to 10 minutes which is really bad but it is the only way to solve the problem and there is a lot of codes on the site and I need to find the problem. If I use DOS attack tool, can I find the page/code block that is causing this issue? If I can, what is the best tool to test it?
Cheers!
EDIT
I tried to check the Event Logs and found the following warning. I don't know if it is issue will keep digging now.
Exception information:
Exception type: HttpException
Exception message: Request timed out.
Check the event log
Turn on Health Monitoring
If you use the 'Failed Request Tracing' and it'll produce a nice output which will then tell you what is causing the error, down to the module level. This will then give you the first step into where it's breaking down.
Have a read of this article on iis.net → Troubleshooting Failed Requests Using Tracing in IIS 7
I would attach visual studio to IIS and break the debugger when a deadlock occurs. You can then inspect the call stack of the running threads.
Code Project has a nice article on how to do IIS remote debugging.
Of course, you can very well set up up a test machine with a local IIS and local Visual Studio .NET and do this without the need to remotely debug.
We have a C# web application, and the latest deploy doesn't work on our Windows Small Business Server 2008 (IIS7). The exact copy of that site runs fine on my Windows 7 machine (IIS7.5). The previous version and other builds still work on the Server 2008 R2 machine, but this itteration doesn't.
I've checked the W3SVC logs, but no requests are logged. I've checked the eventlog for errors, but no errors are logged. I also checked in fiddler, but the request just doesn't get a response as far as I can tell (Result column remains -)
When you open the url, the browser will just keep loading (no timeout).
Is there anything else I can check or enable to debug this IIS7 behaviour?
Thanks in advance,
Nick.
UPDATE
I published the application again & created a new site in IIS, and this new version works. While my the immediate problem is solved at this time, I would still like to know how to debug IIS7, see how it works & why it would keep loading infinitely.
First, I would drop a regular .html file into the sites directory. Then I would have a browser request that specific static file. This would bypass the .net engine and should be logged.
If for some reason it doesn't work and/or isn't logged then there are other things to check, let us know.
Assuming that it does serve the file and you are pointing to the correct machine then inspect your global.asax file and remove any type of error handling you might have. Also turn off the custom errors section of your web.config. Both of which could result in the server essentially spinning off into nothingness if improperly coded. If you have any type of additional threads you are spinning up on access, then see if you can turn those off or add additional logging.
Next, look in the HTTPERR logs to see if you can identify what's going on. These are located at
%SystemRoot%\system32\LogFiles\HTTPERR\httperr*.log
Info about this log file is at: http://support.microsoft.com/default.aspx?scid=kb;en-us;820729
If your app uses ADO then there is chance that depending where the build occurred on Windows 7 or not and whether SP1 is installed or not (at the time of the build) that your build is broken by some Micorsoft ADO-update contained in SP1 (see http://www.codeproject.com/Articles/225491/Your-ADO-is-broken.aspx).
If no requests are logged in the W3SVC logs then it probably means that IIS is not recieving the request at all - likely due to firewall configuration or similar.
You should diagnose why IIS is unavailable (for example by attempting to serve some static content) and then try again.
Try these:
re-register asp.net runtime with your IIS7
make sure the asp.net extension for the correct version is set to Allowed in 'ISAPI and CGI restrictions' in your IIS
Running the code on my local box is running just fine. As soon as I load the code on my server it is having issues. I can't see the issues because my UI code is calling a webservice via jquery and the webservice is calling into the .cs file that is having an issues. The webservice just returns a failure to the jquery.
Any ideas or help is greatly appreciated.
Use the Remote Debugging tools to attach to the W3WP process on the server.
In short, you will need to add lots of logging in the area of code which is behaving oddly to give you clues as to what is happening on the server.
If the webservice is running on ASP.NET, you can use the built-in logging by enabling trace in your Web.config, and then logging likethis : HttpContext.Current.Trace.Write("hello");. All of the HTTP queries and your custom logging can then be viewed by going to http://host/Trace.axd
If not on ASP.NET you can either use a library like log4net or roll your own.
Although you could use Yuriy's approach, i wouldn't recommend it since debugging any process as such in production will ensure than none of your other pages will execute during that time since you would have hit the breakpoint.
Add Debug statements inside your Web Service... something like System.Diagnostics.Debug.WriteLine("write more information here");
Run DebugView on the Production server.
http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx
Hope this helps,
Rahul
I am writing a WinForms app which will execute some web UI tests written in a web testing framework.
Is there a way I can get the error on the page being tested (I specify the page through a method parameter) without screenscraping the page? For example, if it throws:
A potentially dangerous Request.QueryString value was detected from the client
How can I detect this?
EDIT:
One way would be to scrape just the title.
I would actually suggest you look into something called ELMAH. If you put ELMAH on your ASP.NET website it will automatically log and handle all the exceptions that get thrown by your app as you are testing it. You can have it store all the entires as XML files or in a database. You can also have it email you directly with a copy of the Yellow Screen of Death (including stack trace).
This would be a lot easier for you then trying to program the same functionality into your winforms app. Just use your app to beat the ASP.NET site up and let ELMAH handle the error logging.
What about trapping the error at the Application level (with a global handler in .asax) and sending the exceptions data to a db?
Which you can then query.
Hmm, or even, implementing a WCF dual binding, that you call the clients listening on, when an error occurs. Your windows form can be a proxy waiting for notifications. But maybe, that might not be a good idea, as you would want to have your test, separate from your application.
What about using something like Enterprise library to log to an MSMQ, which you can be listening on via the windows form?
EDIT - the ELMAH suggestion above looks good as well