For Windows applications, it might be a good idea to use the EventLog to log application errors because the EventLog is very powerful yet very simple to use. However, it might not be a good idea to use it to log ASP.NET web application errors. Why? There are several reasons:
- It’s all about security. In the malicious cyber world, the security of the web application is a very big concern of any company, if not the biggest concern. By default, the user token of the ASP.NET worker process is ASPNET (or NetworkService for applications that run on Internet Information Services [IIS] 6.0). It has the least privilege as far as the file access permission and the system access permission are concerned. So, it is not surprising for a web application to get an “access denied” error when trying to log errors to the EventLog. If you really want to use EventLog to log your web applcation error, then you have to modify your web server’s registry to get it work. Here is a “Help and Support” article from Microsoft regarding the registry edit. However, granting this permission to web application can open a serious security vulnerability.
- If you use the EventLog to log every type of errors of the web application, then the EventLog may get filled up very quickly, at which point any attempts to write to them will cause exceptions to be thrown, including the web server itself.
- Although the EventLog is very simple to use, it comes at a cost. Reading and logging events are relatively resource intensive. On a server with multiple web applications running, it might put a heavy load on the server when using the EventLog to log the web application errors.
Therefore, I would not recommend to use the EventLog to log ASP.NET application errors. Even for the Windows application, it is important to remember that event logging is very resource intensive in terms of disk space, processor time, and other system resources, therefore, it should be used to log only essential information.