I have an ASP.NET-based web app on Azure with a Web API. Yesterday, I started to get exceptions from the app whenever one of the API calls was invoked.
I don't have an exception logger intercepting application exceptions at the moment, however, I do have audit logging on each of the API calls which 99% of the time catches exceptions and reports problems to me.
In this particular case, it appears an exception is occurring further up the stack from the audit logging. There's not much code I have written which is invoked above there to be honest. There is also an IIS error page configured, so exception information is not passed down to the client. I have had a look in the event log and there's nothing in there.
In reaction to the problem, I spun up a new Azure instance, made that live and relegated the problematic instance to staging. The new instance works fine. If I restart the (now) staging instance by reconfiguring web.config to disable IIS errors then that instance will also work fine!
So does anyone know how I can extract unhandled exception information from a running app domain without having to restart it or affect it in any way?
I will be putting exception logging in soon, don't worry :-) But if there is a way to crack this without having to wait for another occurrence of the problem then that would be great!
UPDATE:
I logged onto the server and managed to get the following information from the "detailed response":
HTTP Error 500.0 - Internal Server Error The page cannot be displayed
because an internal server error has occurred. Detailed Error
Information:
Module ManagedPipelineHandler
Notification ExecuteRequestHandler
Handler System.Web.Http.WebHost.HttpControllerHandler
Error Code 0x00000000
Requested URL http:// 10.77.52.122:80/api/Login
Physical Path E:\sitesroot\0\api\Login
Logon Method Anonymous
Logon User Anonymous
Request Tracing Directory
C:\Resources\directory\34c6b40352d4449d8a19274caa328300.Web.UI.DiagnosticStore\FailedReqLogFiles\Web
I then configured Failed Request Tracing - which promptly made the error go away!
Anyone have any ideas? I'm probably going to have to wait for it to happen again, but by then there'll be some more exception logging.
thanks
Kris
Related
I have configured the Application Initialization for a Web App running on Azure, the reason for that is to improve the "warm up", because I have some issues with Scale-out, the instance is not ready for the connection then I got some servers errors.
There is a good doc from Microsoft about that:
https://learn.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-application-initialization
I am not sure how to check if Application Initialization is working.
Are there any logs that I can check?
IIS doesn’t provide separate log files for each modules and function, but for each website. So application initialization for a web to improve the “warm up”, can be checked by some function.
Advanced Logging is helpful and analyze the log file of the website which applied application initialization module. You can get it from here
Fail Request Tracing also can help you to trace request when you try to access the website to test whether the initialization is successful, especially using url rewrite with application initialization. Enable fail request tracing from here.
I have an MVC+SignalR application that has a lot of Reactive Extensions subscriptions flying around, all of which are projections of data coming from a Socket in realtime. Some of these subscriptions are not working as expected, and when they raise an exception it just goes into the void unless I'm debugging.
I had hoped that I could use Elmah to automatically log these unhandled exceptions, but it seems that unless the exception occurs on the same thread that's processing the request/response, eg it causes a yellow screen of death, Elmah isn't touching it. So my question is twofold:
Can I get Elmah to automatically log exceptions on background/worker processes?
If the answer to #1 is "no", what's my next best option, other than wrapping my subscriptions in try/catch blocks at a very high level?
Ad 1) If it doesn't happen already it probably doesn't.
I don't know how exactly you use background threads, but I will try to explain were ELMAH handling is working. ELMAH is integrated into ASP.NET pipeline, and when the error occurs it is handled by ASP.NET pipeline, which shows error page (like http error 500) and invoke ErrorLogModule. Moreover quoting Using HTTP Modules and Handlers to Create Pluggable ASP.NET Components -> Adding ELMAH to an ASP.NET Web Application
The section adds the ErrorLogModule HTTP module to the
ASP.NET HTTP pipeline. Make sure you include this
setting, otherwise ELMAH won't be listening for the Error event, and
therefore won't be logging any unhandled exceptions.
Ad 2) Because you are using Reactive Extensions you can handle onError in which you can automatically log into Elmah. If you don't want to writer everywhere error hangling in OnError, just create your own function or method extension which will wrap it automatically for you. Writing into ELMAH manually is simple just call:
Elmah.ErrorSignal.FromCurrentContext().Raise(ex);
My Azure .Net web app uses a shared cache role which can sometimes throw an exception meaning, "retry later" if it is hot swapping. Currently, that causes my web app to error. However, this is thrown before my app has even started up since it is the framework/IIS which has attempted to setup the cache and failed.
How can I catch these exceptions and do something useful when redirecting to an error page would still require my app and config/cache to load, which would cause the exceptions again? Even if I could catch the exception in Application_Error, I don't think I can retry the connection to the cache because I didn't create it in the first place.
Few questions :
Didn't clearly get your question. So it's your client calling cache, who is getting these errors right?
Are you using session state provider for cache? If not, When you said you are not making connections to the cache, what did you mean?
What is the exact error?
Is it intermittent? Is it always happening during role startup, the case u mentioned here?
In Asp.Net we are using the global Application error handler to log all exception that occur. The logs are extremely helpful of course. However, when a request time out occurs, the exception does not include the trace of the code that was being executed when the timeout occurred because the exception is not thrown by the code itself.
Is there anyway get that data programatically ?
You should be able to find that through the event viewer in the application logs. You can also run something like elmah or glimpse to log and track exceptions on your web application. They will give you some additional info as well as give you a better view of what's going on in your web application
... will the Application_Start method be ran again for the next request(s) or not?
Does it depend on ASP.NET version, hosting server version and/or other context?
I am trying to determine if it's a good thing to load critical assemblies there or not. For example data access assemblies which are vital to the functioning of the whole application or not. Failure to load such assembly would make subsequent requests useless.
Application_Start will be fired only once for each web application so in your case, the start will not happen again for subsequent requests.
Typically, I prefer to put one time start-up code in the application start within try-catch and if there is an exception then set the global error flag. In each BeginRequest, the flag is checked and if it is set, user is redirected to a custom error page indicating the site is down and please contact the administrator.