Writing new features for your ASP.NET Core application can be exciting, but users will unavoidably run into failed requests. Are you familiar with troubleshooting ASP.NET or IIS errors on your servers? It might be tempting to slam on your desk and express how annoyed you are.
ASP.NET Core and Windows, on the other hand, offer multiple logs where unsuccessful requests are recorded. This can provide you with the information required to address unsuccessful requests and goes beyond basic IIS logs.
Learn About the Six Types of IIS Logs
You might be familiar with standard IIS logs if you have worked with ASP.NET Core applications for some time. These logs are just the first tools in your troubleshooting arsenal.
If you are unable to find anything in your IIS log file or are searching for more specific error messages, there are other places you can check.
1. Standard IIS Logs
You can find all of the web requests that go through your IIS site in the standard IIS logs.
You’re able to view the “Logging” feature in IIS Manager. By clicking on this, you can see where your IIS logs are being written to and confirm that they are enabled.
Your logs should be located in folders with names corresponding to your W3SVC site IDs.
Every request that is logged into your IIS log by default contains a number of important fields, such as the URL, querystring, and error codes that are obtained from the status, substatus, and win32 status.
These status codes can provide further details about the actual error.
#Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) cs(Referer) sc-status sc-substatus sc-win32-status time-taken 2019-09-13 21:45:10 ::1 GET /webapp2 - 80 - ::1 Mozilla/5.0 - 500 0 0 5502 2019-09-13 21:45:10 ::1 GET /favicon.ico - 80 - ::1 Mozilla/5.0 http://localhost/webapp2 404 0 2 4
The standard HTTP status codes, which are 200 for OK, 404, 500 for errors, etc., are entered into the “sc-status” and “sc-substatus” fields.
If you look up the code, the “sc-win32-status” can provide you additional information that you might not be aware of. These error codes are basic Win32 ones.
The endpoint for which the log message is intended is also visible under “cs-uri-stem.” For instance, “/webapp2.” This can point out any issues with your application right away.
“Time-taken” is another crucial piece of information to consider. This provides you with the request and response’s round-trip time in milliseconds.
As an aside, one of the built-in log management features of Retrace is the ability to query across all of your IIS logs.
2. IIS Log Doesn’t Contain Your Request? Your IIS error log is HTTPERR.
In your IIS log, each and every web request ought to be visible. If not, there’s a chance that IIS wasn’t running or that the request never reached it.
It’s also feasible that IIS Login is turned off. It might be going to HTTPERR if IIS is running but you are still not seeing the log events.
Before reaching IIS, incoming requests to your server first go via HTTP.SYS. These kinds of mistakes are recorded in HTTPERR.
Timeouts, 503 Service Unavailable, 400 Bad Request, and other similar errors are common. the integrated HTTP error codes and messages.SYS are typically quite thorough.
Where are the HTTPERR error logs?
C:\Windows\System32\LogFiles\HTTPERR
3. Check Windows Event Viewer for ASP.NET Core Exceptions.
Unhandled 500 level exceptions are automatically logged by ASP.NET Core and sent to the Windows Application EventLog. The ASP.NET Core Health Monitoring feature takes care of this. The system.web/healthMonitoring section of your appsettings.json file contains the settings for it.
The fact that there is a rate limit on the amount of errors written to the Application EventLog is not widely known. Thus, you might not notice your mistake!
It will only log the same kind of error once every minute by default. Disabling the writing of any errors to the Application EventLog is another option.
Can’t find your exception?
It’s possible that the EventLog does not contain your exception. Compatibility issues with the health monitoring feature may cause ASP.NET Core to fail to write any errors at all to ASP.NET, depending on whether you are using WebForms, MVC, Core, WCF, or another framework.
4. Failed Request Tracing for Advanced IIS Error Logs
Among the features of IIS that is most likely not used is failed request tracing, or FRT. That being said, it is extremely powerful.
It functions as an excellent IIS error log and offers strong IIS logging. IIS Manager has enabled FRT, which can be set up via rules for all requests, slow requests, or only specific response status codes.
It can be set up through a website’s “Actions” section:
The one issue with FRT is its extreme detail. Think of it as your application’s stenographer. Every aspect and stage of the IIS pipeline is monitored. Deciphering a single request can take a lot of time.
5. Get the Complete Exception to Show in ASP.NET Core
In the event that all other options are exhausted and the issue is reproducible, you may change your ASP.NET Core appsettings.json file to view exceptions.
For significant security reasons, server-side exceptions are typically hidden from view within your application. Alternatively, a custom error page or the yellow screen of death (YSOD) will appear.
To make exceptions visible, you can edit the configuration files for your application.
ASP.NET
You could use remote desktop to access the server and set customErrors to “RemoteOnly” in your web.config so you can see the full exception via “localhost” on the server. This would ensure that no users would see the full exceptions but you would be able to.
If you are OK with the fact that your users may now see a full exception page, you could set customErrors to “Off.”
.NET Core
The way error handling functions has been entirely redesigned by.NET Core in comparison to earlier ASP.NET versions. The DeveloperExceptionPage must now be used in your middleware.
You have unparalleled flexibility with.NET Core when it comes to managing and viewing your errors. Additionally, it facilitates the wiring of instrumentation such as Retrace.
6. Locating ASP.NET Core Exceptions with a.NET Profiler
Even if your code hides any exceptions that.NET throws, .NET profilers like the free Prefix can gather all of them.
To assist you in optimizing your code while you write it, Prefix is a free ASP.NET Core profiler that you can install on your workstation. Along with much, much more, Prefix can display your HTTP calls and SQL queries.
Bottom Line
It is not enjoyable to track down IIS logs or IIS error logs or attempt to reproduce an error in production. It’s likely that many more mistakes are being made that you aren’t even aware of. You had better have a simple way to see errors on your site when a customer contacts you to report them!
Monitoring application errors is among the most crucial tasks that each development team should undertake. Try Retrace if you need assistance; it can gather all exceptions from all of your servers and apps.
