System.Security.SecurityException: The source was not found, but some or all event logs could not be searched. Inaccessible logs:
Adding Event logging works the same with VISTA as it does in XP. Unfortunately there is no programmic method to make it work the first time.
The symptoms are you check and check the event logs to see where your entries are but alas nothing. Under VISTA you will see a sporadic "Uable to find Type Initializer" in the event logs. The later is an indication that you have not yet performed the following:
For XP , 2003, and Vista
1. Right Click on "My Computer"
2. Select "MANAGE"
3. Select "USERS AND GROUPS"
4. Drill Down on "GROUPS"
5. Double-Click on "ADMINISTRATORS" and select "ADD" on that property sheet.
6. Click on "ADVANCED" and then "FIND NOW"
7. Select "NETWORK SERVICE" and ADD - OK...
Illustration here:
Fire up your application and now it should create and start recording your log entries assuming you have code implemented similiar to such:
public void LogMessage(string exMessage)
{
EventLog EventLog1 = new EventLog();
try
{
//replace EVENT_LOG with a configurable value
string EVENT_LOG = "Sites-Easy Web Application";
if (!EventLog.SourceExists(EVENT_LOG))
EventLog.CreateEventSource(EVENT_LOG, "Application");
EventLog1.Source = EVENT_LOG;
EventLog1.WriteEvent(new System.Diagnostics.EventInstance(1, 1), new string[] { exMessage });
}
catch (Exception ex)
{
throw ex;
}
}
Once you have verified that the logging is taking place, for security purposes you SHOULD repeat the process and REMOVE the NETWORK SERVICE from the Administrative group. The error only occurs when there is no Event Log that matches the name requested and the application code is trying to create one. Otherwise, if the event log is found IIS has enough rights to write entries. Having NETWORK SERVICE as part of the Administrative group is potentionally catastrophic if some third party tool is installed and has malware, spyware, or other anti-productive qualities written within...
If you haven't checked out the series of articles Peter Bromberg has written on "Fire and Forget" Asynchronous pattern - you should. Most notably - the easiest of the series to adopt to your own code is :
I had tried his other article on Logging but since I use alot of interfaces I found it nearly impossible to adapt. However, the before mentioned article, clued me on what to do when trying to invoke a method that is in a dynamically loaded assembly. Create a stub, that once the assembly is loaded - the delegates will work as intended.
For instance:
In an interface you can not declare:
delegate void LogMessageDelegate(...some parameters)...
The IInterface doesn't accept it and so you should create what I call a stub method:
For example in the Interface (IDAL)
void LogMessageAsynch( some parameters)
In the class being invoked...
then you can do the:
public delegate void LogMessageDelegate(string exMessage);
public void LogMessageAsynch
(
string briefEntry,
string fullEntry,
Severity severity,
string module,
string additionalInfo
) {
HttpContext Context = HttpContext.Current;
// Get section ID
string displayMessage = (severity.ToString() + module + ": " + briefEntry + "<br />" + fullEntry + "<br />" + additionalInfo + "<br />");
BackgroundProcess(new LogMessageDelegate(LogMessage),
new object[] { displayMessage });
The above code implements the logging logic earlier in the article. I will say transforming my logging to do the ASYNCH process, as Peter suggests, did improve the perf of the display of the pages while using SQL Profiler. SQL Profiler indicated that the majority of log entries occurred AFTER the loading of the page - and before pages would wait and wait until all of the activity logging was committed. This actually is a decent benefit for those writing logging functions for debugging code as well as in a production site where seeing entries in real-time anyways would not be possible any how.