0

I found several topics on this already, but somehow they all managed to avoid the real problem solution/assumed the obvious.
(e.g. here, here, here, here, here)

I am checking for and creating new event log + source during installation, and specifying them to be used during operation, but still somehow "EventSourceName" events end up in Application Log.

Why is that?


Here are snippets out of my code:

Installer:

namespace Service_Name
{
    [RunInstaller(true)]
    public partial class ProjectInstaller : System.Configuration.Install.Installer
    {
        public ProjectInstaller()
        {
            if (!System.Diagnostics.EventLog.SourceExists("EventSourceName"))
            {
                System.Diagnostics.EventLog.CreateEventSource(
                    "EventSourceName", "EventLogName");
            }
            InitializeComponent();
        }

        private void serviceProcessInstaller1_AfterInstall(object sender, InstallEventArgs e)
        {

        }
    }
}

Service:

public Service_Name()
{
    InitializeComponent();
}

protected override void OnStart(string[] args)
{
    ServiceEventLog = new EventLog();
    ServiceEventLog.Source = "EventSourceName"; // This is different from Service Name
    ServiceEventLog.Log = "EventLogName"; // This is different from Service Name
    ..
    ServiceEventLog.WriteEntry("Service Init");
    Worker = new Thread(CodeWorker);
    Worker.Start();
}

private void CodeWorker()
{
    //.. operational code
    while (true)
    {
        try
        {
            //.. operational code
            ServiceEventLog.WriteEntry("<operational event data here>", (EventLogEntryType)4, 0);
        }
        catch (Exception Error)
        {
            ServiceEventLog.WriteEntry(string.Format("<error event data here>", (EventLogEntryType)1, 0);
            throw;
        }
        //.. operational code
    }
}

As it turns out, the code works perfectly as is, however there is important thing to remember when working with event log;

EventLog.CreateEventSource Method has an important footnote:

If a source has already been mapped to a log and you remap it to a new log, you must restart the computer for the changes to take effect.

I had mapped the source prior, to another event log which was named the same as Service itself. Using same name as the service itself caused multiple other issues and I ended up fixing that by using another log name, but did not restart test system prior to doing tests on new code version.

But as Caius Jard pointed out below, parts of the code are redundant:
ServiceEventLog.Log = "EventLogName" does not need to be specified as Source is already registered to Log.

DerStarkeBaer
  • 669
  • 8
  • 28
ichihaifu
  • 23
  • 7

1 Answers1

2

The documentation states "If you change the Log property after the Source property has been set, writing a log entry throws an exception.".

The sample code on MSDN just sets the Source property and then calls WriteEvent, it does not then set the Log beforehand or after setting Source

I recommend you remove the call to setting the Log property; I suspect your call to WriteEvent is crashing, and being in a try catch the call in the catch is also crashing. Perhaps it's not an ideal code structure to "try writing to this log and if it fails, try writing to this log" if it's the "writing to log" that is failing

Caius Jard
  • 72,509
  • 5
  • 49
  • 80
  • At least there is no thrown error that I can find, but adjusting ordering or entirely removing `ServiceEventLog.Log` property call from `Onstart` made no difference: Events are still written to Application log. – ichihaifu Mar 11 '20 at 08:51
  • Also, for testing purposes _(this is odd)_: Writing to event log via powershell also ends up in application log: `Write-EventLog -LogName "EventLogName" -Source "EventSourceName" -EntryType Error -EventId 0 -Message "test message from powershell"` – ichihaifu Mar 11 '20 at 08:58
  • Looks like my witnessed behavior is simply due to prior testing I was doing, and I had not restarted the test system. Sample code page had important footnote that I had missed: **If a source has already been mapped to a log and you remap it to a new log, you must restart the computer for the changes to take effect.** Code is perfectly fine as is, but I will take your suggestion and remove log mapping from the program itself, as it is redundant. – ichihaifu Mar 11 '20 at 09:29
  • I did also catch a similar reference about waiting for some time/restarting after the installer creates the event log, before the log can be written to because windows only periodically refreshes its knowledge of which logs exist. Sorry I didn't mention it as it might also have pointed you in the right direction – Caius Jard Mar 11 '20 at 09:31