Even while adding new functionality to your ASP.Net application can be thrilling, users will always experience unsuccessful requests. Do you have any knowledge of how to fix IIS or ASP.NET issues on your servers? It may be alluring to bag on your desk and complain about how annoyed you are.
However, Windows and ASP.NET offer a variety of logs in which unsuccessful requests are recorded. This goes beyond standard IIS logs and can provide you with the knowledge you need to handle unsuccessful requests.
Get Started with 6 Different IIS Logs
If you have experience working with ASP.NET apps, you may be accustomed to the typical IIS logs. These logs are just the first set of tools in your troubleshooting toolbox.
If your IIS log file is empty or you need to uncover more specific problem messages, there are few additional places to look.
1. Standard IIS Logs
Every web request that passes through your IIS site will be recorded in the standard IIS logs.
You may see a “Logging” feature in IIS Manager. You may check to see if your IIS logs are enabled and to see where they are being written by clicking here.
You should find your logs in folders that are named by your W3SVC site ID numbers.
Each request that is recorded in your IIS log by default will contain a number of important elements, such as the URL, querystring, and error codes via the status, substatus, and win32 status.
These status codes can aid in more precisely identifying the fault itself.
#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 normal HTTP status codes of 200 for OK, 404, 500 for failures, etc., are displayed in the “sc-status” and “sc-substatus” columns.
You can learn additional information from the “sc-win32-status” if you look up the code. These Win32 error codes are fundamental.
Also visible under “cs-uri-stem” is the endpoint for which the log message was written. For illustration, “/webapp2.” This might point out trouble locations in your application right away.
“Time-taken” is another crucial piece of information to consider. This tells you how long it took for the request and response to return, in milliseconds.
By the way, Retrace’s built-in log management feature allows you to query across all of your IIS logs if you’re using it.
2. Use HTTPERR as Your IIS Error Log
In your IIS log, each and every web request should be visible. If it doesn’t, the request might not have reached IIS or IIS might not have been operational.
Additionally, IIS Login might be disabled. It may be flowing to HTTPERR if IIS is active but you’re still not seeing the log events.
Before going to IIS, incoming requests to your server pass through HTTP.SYS first. These failures are recorded in HTTPERR.
Timeouts, 503 Service Unavailable, 400 Bad Request, and other similar problems are frequently encountered. built-in HTTP error messages and error codes.SYS are frequently fairly specific.
The HTTPERR error logs aren’t present.
C:\Windows\System32\LogFiles\HTTPERR
3. Check ASP.NET Exceptions in Windows Event Viewer
By default, ASP.NET will log unhandled 500 level exceptions to the Windows Application EventLog. This is handled by the ASP.NET Health Monitoring feature. You can control settings for it via system.web/healthMonitoring in your web.config file.
Very few people realize that the number of errors written to the Application EventLog is rate limited. So you may not find your error!
By default, it will only log the same type of error once a minute. You can also disable writing any errors to the Application EventLog.
Can’t find your exception?
Your exception may not be found in the EventLog. Due to compatibility issues with the health monitoring feature, you may experience issues with ASP.NET not writing any errors to ASP.NET if you use WebForms, MVC, Core, WCF, or other frameworks.
In addition, if you install Retrace on your server, it will catch every single exception thrown in your code. It understands how to instrument IIS features.
4. Failed Request Tracing IIS Error Logs
Failed request tracing (FRT) is one of the most underutilized features in IIS. It is, however, extremely potent.
It provides reliable IIS logging and serves as an excellent IIS error log. FRT is enabled in IIS Manager and can be configured using rules to apply to all requests, slow requests, or specific response status codes.
You can configure it in a website’s “Actions” section:
The only issue with FRT is that it is extremely detailed. Consider it your application’s stenographer. It monitors every detail and step of the IIS pipeline. You can waste a lot of time trying to figure out a single request.
5. Make ASP.NET Display the Entire Exception
If other avenues fail you and you can reproduce the problem, you could modify your ASP.NET web.config to see exceptions.
Typically, server-side exceptions are disabled from being visible within your application for important security reasons. Instead, you will see a yellow screen of death (YSOD) or your own custom error page.
You can modify your application config files to make exceptions visible.
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
.NET Core has completely changed how error handling works in comparison to previous versions of ASP.NET. In your middleware, you must now use the DeveloperExceptionPage.
6. Using .NET Profiler to Find ASP.NET Exceptions
.NET profilers such as Prefix (which is free!) can collect every single exception thrown in your code, even if it is hidden.
Prefix is a free ASP.NET profiler that runs on your workstation and assists you in optimizing your code as you write it. Prefix can also display SQL queries, HTTP calls, and much more.
Conclusion
It’s not fun trying to reproduce an error in production or chasing down IIS logs/IIS error logs. We hope that above article help how to find ASP.NET failed request on your application. If you find this article helpful, please feel free to share it.
Are you looking for an affordable and reliable Asp.net core hosting solution?
Get your ASP.NET hosting as low as $1.00/month with ASPHostPortal. Our fully featured hosting already includes
- Easy setup
- 24/7/365 technical support
- Top level speed and security
- Super cache server performance to increase your website speed
- Top 9 data centers across the world that you can choose.
Javier is Content Specialist and also .NET developer. He writes helpful guides and articles, assist with other marketing and .NET community work
