If my web service runs into some initialization error during startup, such as not being able to connect to its database, is it possible for me to stop the website? This will make it easier for administrators to see that something has gone wrong without checking the log files and would analogous to terminating an application early if the command line parameters are wrong. One more caveat, I can't use Microsoft.Web.Administration.
You could raise a specific type of Exception for those fatal errors and handle it on Application_Error.
When those catastrophic events happen and are handled there you could just generate an App_Offline.htm that'll bring the website down without phisically stopping it on IIS.
This will make your website return 503 Service Unavailable which is probably the most semantically correct way of a web service communicating it's down because of a catastrophic event.
Related
I am working on an application that will run in Kubernetes. Kubernetes relies on the application to know if it is healthy or not.
So, I need to know when I get a critical exception thrown. By "Critical", I mean Out of Memory, Stack Overflow, etc. Things that mean that the container should be killed.
I have seen things in ASP.Net Core that allow you to show an error page when an exception happens, but I need this to happen with both UI and Web API applications. And I don't really want it to interact with my UI at all (on the ones that have a UI ).
Is there an event (or something similar) that is raised when an exception was thrown in an ASP.Net Core application?
A .NET application will not be able to handle “critical” issues like memory issues or stack overflows in a way that it can report about its own health. There are basically two possible outcomes with unexpected errors: The application can handle the problem, in which case the ASP.NET Core application is expected to work properly for future requests, or the process terminates abruptly.
Observing the latter should be done from the outside. You can do this for example by checking if the process is still alive in your container.
Another option would be to employ health checks which is a way for an ASP.NET Core application to report about its own health:
Health probes can be used by container orchestrators and load balancers to check an app's status. For example, a container orchestrator may respond to a failing health check by halting a rolling deployment or restarting a container. A load balancer might react to an unhealthy app by routing traffic away from the failing instance to a healthy instance.
So your container orchestrator could check whether the ASP.NET Core application is still able to respond to a health probe, and if it isn’t assume that the application crashed in some way or another, requiring a container restart.
In our ASP.Net application we usually try to handle all our exceptions by catching them in relevant places to give the end user useful error messages, but some exceptions are impossible for us to catch due the place they are thrown.
This is an issue to our server setup since we want to keep the IIS Rapid Fail Protection working as intended, and all errors to be written to our custom error log. So to avoid unexpected resets of the server and flooding our error log, I have added some code in Global.asax.cs to suppress certain kinds of errors. At the moment we are looking at two kinds of HttpExceptions thrown by the IIS itself, to prevent too long URLs (based on the maxUrlLength setting), and to prevent faulty WebResource or ScriptResource requests. These are impossible for us to prevent due to some webcrawlers generating them.
What I'm interested in knowing, that is difficult for me to find info on anywhere is:
Can the referenced HttpExceptions even potentially cause the Rapid
Fail Protection to restart the server? I'm told that any uncaught
exception can cause it, but it seems illogical to me that this kind
of exception should be able to cause it.
If I call Server.ClearError() in the Application_Error() event, is that enough to suppress errors that could cause a rapid fail protection restart?
Or is it already too late at this point? Since we're already in the
process of responding to an unhandled exception.
The Rapid-Fail Protection (here, RFP) feature is meant to protect the system from application pools and worker processes that are not starting properly or are failing often. These issues could be caused by your application(s) or an IIS worker process. The official (albeit old) list of causes can be found here.
Not directly. If the logic that is attempting to handle the error fails, the worker process could crash. This would trigger RFP. Usually, this will not happen because IIS will try to handle an exception in Application_Error.
If your application has gracefully handled the exception in Application_Error, then it stops there. Your exception was "unhandled" at the application level, but IIS was able to handle it (usually serving the "yellow screen of death"). Therefore, the worker process is still healthy and RFP will not be triggered.
I have seen an IIS worker process crash under the following conditions:
Recursive call results in an infinite loop.
Insufficient system resources to process a request (out of memory or memory limit reached).
Web service error response (code/message etc) would you store it in a database? or would you keep the error response in a method.
By the time I'm done with this, there will be hundreds of error response, maybe in the future, thousands? (I dont know yet, depends how large this web service grows).
EDIT: error response is the response returned back to the application via the web service, (not to be confused with error logging).
Error codes aren't designed to look good in UI when something goes wrong. Their main goal is to inform application what happened so that application could react.
If you move the error codes to the database you'll not be able to handle them unless you'll make a standard procedure of handling EVERY error code (for example log it and shutdown the application).
I developed a simple windows service in C# as per this article.
http://www.codeproject.com/KB/dotnet/simplewindowsservice.aspx
I was successfully able to start the service for the first time and stop it. During the following attempts, I was not able to start the service. I got the following information.
The MyNewService service on Local
Computer started and then stopped.
Some services stop automatically if
they have no work to do, for example,
the Performance Logs and Alerts
service.
Please help.
I outlined here a method we're using to debug our Windows services. Maybe this will help you trace the error. Basically this sounds like some error is occurring while trying to execute the OnStart method.
Basically this means the main thread of your service has crashed for some reason. The most common I've seen is filesystem access to it's own log files.
Sometimes you can find the reason in the event viewer, but unfortunately a lot of the time the user you're running the service as won't actually have access to log it's error. A simple thing to do if you're in a dev environment is to just give the service an administrator account temporarily, firstly cause it'll tell you whether the crash is being caused by lack of access (cause it'll work) and secondly if it's not it'll allow it to write to the event viewer. Make sure to take the admin access of f once you fix it though, cause long-term that can be very dangerous.
Did you look in the event log? You can usually get more detailed error information there about the service error. Also, are you writing out to a log with your service? That's another way you could figure out what's going wrong.
You can get to the event log by right clicking on Computer and selecting "Manage". Under System Tools, look under Event Viewer->Application. This is on Windows XP, but other Windows OS's should be similar.
If the service is on your development machine, you should be able get Visual Studio's debugger to attach to it as it starts so that you could identify if anything is causing it to crash. It involves a bit of registry editing as described here: http://blogs.msdn.com/greggm/archive/2005/02/21/377663.aspx
It sounds like your main thread is dying for some reason. Put a call to System.Diagnostics.Debugger.Break() in your service's startup code, e.g., the Main entry point, the service constructor, or the OnStart() method. When you start your service from the Services MMC, you'll be prompted to enter a debug session. Once you're in Visual Studio, open the Exceptions dialog (from the Debug menu) and check the boxes in the Thrown column. Then debug from there to find the problem.
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