I occasionally get asked for this, so I’m going to post it here for
people to find. This is how to put an exception from a .Net
application into a custom log in the event viewer.
Let’s say you catch in exception in your code and you want to put it in the event logs. It’s a piece of cake.
Here is the C# code to do the same thing:
To test this, just creating the following code in a method somewhere:
Where ThrowException does nothing but throws an exception
And you get a nice little entry into your event viewer (I ran it twice, that is why you see 2 entries):
Josh and Dave are both correct in that you cannot create the log source at runtime without admin privs. If you are running a windows app and are a member of the admin group, you won’t have a problem. If you have changed your processes model username from MACHINE to SYSTEM, you won’t have a problem with Asp.Net applications. But under most circumstances, follow their advice and either create the event source before hand, or handle it at runtime.
How would giving the assembly full trust make a difference?
I would suggest that any event source creation be done at “install” time, (using a class derived from Installer, and the InstallUtil.exe or a setup package), rather than at runtime.
Wasn’t thinking when I named my event log AspNetError. Didn’t intend this to be asp specific, but the answer is to give the assembly full trust or use impersonation. The AspNet account, by default, does not have access to the event logs.
Josh and Dave are both correct in that you cannot create the log source at runtime without admin privs. If you are running a windows app and are a member of the admin group, you won’t have a problem. If you have changed your processes model username from MACHINE to SYSTEM, you won’t have a problem with Asp.Net applications. But under most circumstances, follow their advice and either create the event source before hand, or handle it at runtime.
I agree. You need ADMIN privileges to create an eventlog source. You’ll only have those at Install time, not runtime.
How would giving the assembly full trust make a difference?
I would suggest that any event source creation be done at “install” time, (using a class derived from Installer, and the InstallUtil.exe or a setup package), rather than at runtime.
Wasn’t thinking when I named my event log AspNetError. Didn’t intend this to be asp specific, but the answer is to give the assembly full trust or use impersonation. The AspNet account, by default, does not have access to the event logs.
Hey dude,
What about security errors you might get from aspnet when using the above?
- SM