Writing to the EventLog from a Web Application

Introduction

When I was a young lad in college, I wrote undetectable viral hacks, keyboard sniffers, and collected more passwords than I care to count. (Thankfully, the statute of limitations—this was 20 years ago—has run out.) I never stole anything or wrecked anyone's data, but I did encourage a young fellow to send roses to his girlfriend and hooked a football player, Napolean XXXXXXX (last name omitted), up on a blind date. I understand the allure of going and being places one isn't allowed, but this crap makes life a pain in the butt for the rest of us.



I wonder whether you should hate hackers and those nitwits who tweak Trojans, so the rest of us have to keep sending money to McAfee?! I also wonder if maybe the sparring and jousting among programmers, Microsoft and hackers, and cyber thieves aren't necessary to push the technology forward, at least as far as security is concerned, so we all are protected from worse—cyber terrorists. With the economy in the shape it's in, an effective cyber terror attack could push the economy into the trash compactor and send normally sane people running for the bunker. The unfortunate net effect in my little community is like taking off my shoes at airport security—I have to re-learn how to do little things over.
Clearly mucking about in the Registry or event logs could be a hugely potential security risk, so this is just one of many areas where the wheel-of-torture that is security gets tightened down. If you have had any difficulties creating and using the event log for ASP.NET, this article should help you "learn" to do it right (again).

Writing to the EventLog

If you wanted to write to the EventLog, you can still create an instance of the EventLog and call WriteEntry. By default, your entry will be written to the Application log. If you wanted to create a new log source—a dictionary entry for your application—you could write code like that shown in Listing 1.
Listing 1: Code that tries to create an event source but is doomed to fail due to a lack of permissions to the Security log.

Imports System.Diagnostics

Partial Class _Default
   Inherits System.Web.UI.Page

   Protected Sub Page_Load(ByVal sender As Object, _
      ByVal e As System.EventArgs) Handles Me.Load

      If (Not EventLog.SourceExists("MyApp")) Then
         EventLog.CreateEventSource(("MyApp", "Application")
      End If

      'Write entry here
      EventLog.WriteEntry(SOURCE, "Test")
   End Sub
End Class

The code checks to see whether the source exists; if not, it creates it. The EventLog uses queuing (it might be DCOM, I don't remember and it's not important right now), but there can be a latency between doing things to the EventLog and those tasks actually completing. In short, this means that it is better to create an event source in advance of needing it.
The problem with the preceding code is that it won't work. If you try to create or use a custom log, you are going to get a security exception (see Figure 1)—for sure under Windows Vista, Visual Studio 2008, and IIS 7 (and Cassini). I am not sure how many other back-combinations will cause this error; the point is that it's going to be a challenge going forward. Worse, having searched the Web thoroughly, Google returns blogs and articles that instruct one to hack the Registry security permissions for EventLogs (bad idea and not a sustainable approach) or write a look that edits the Registry with code (also clumsy). The best approach is none of these.




See full detail: http://www.codeguru.com/vb/vb_internet/aspnet/article.php/c15905/