Runtime: EventSource is not emitting ETW logs.

[hjc4869]

EventSource on .NET Core 2.1.300 x64 (Running on Windows 10.0.14393.2368 x64) is not emitting event logs, thus logs cannot be viewed in eventvwr.msc
I'm not sure if it is unavailable by design, or I'm missing something important.

Sample code to reproduce:
EventSourceTest.Logging.dll

using System.Diagnostics.Tracing;

namespace EventSourceTest.Logging
{
    [EventSource(Name = "SampleEventSource", Guid = "b10d9bdd-6939-484f-93a9-be419202e3ac")]
    public sealed class SampleEventSource : EventSource
    {
        public static SampleEventSource Log = new SampleEventSource();
        [Event(1, Message = "MyEvt1", Level = EventLevel.Critical, Channel = EventChannel.Admin)]
        public void MyEvt1(string arg1)
        {
            WriteEvent(1, arg1);
        }
    }
}

EventSourceTest.dll

using System;
using EventSourceTest.Logging;

namespace EventSourceTest
{
    class Program
    {
        static void Main(string[] args)
        {
            SampleEventSource.Log.MyEvt1("test");
        }
    }
}

Use eventRegister.exe tool to generate manifest, and use wevtutil to register the manifest

eventRegister EventSourceTest.Logging.dll
wevtutil im EventSourceTest.EventSourceTest.etwManifest.man /rf:<Full/Path/To/etwManifest.dll> /mf:<Full/Path/To/etwManifest.dll>

When published with dotnet publish -c Release -f net47 -r win-x64, after running the program, the log shows correctly in Event Viewer. While with dotnet publish -c Release -f netcoreapp2.1 -r win-x64, nothing appears.

[stephentoub]

cc: @brianrob

[tmartinholm]

Any progress on this one?

[JRBANCEL]

Have you tried capturing the events with PerfView?
I thought I was hitting the same issue since I wasn't seeing my events in Event Viewer (while it used to work), but PerfView can capture all my events: netcoreapp2.1/win-x64.
Microsoft Message Analyzer captures them as well.

This suggests the problem could be somewhere else.

[Masus]

Can verify this as well. Events are captured in event viewer if the target is .NET framework 4.6.2 but is not showing up when target is netcoreapp2.2. This prevents us from logging to event viewer in any of our .net core apps.

[brianrob]

@noahfalk @jorive this is specific to channel support.

[Masus]

Any updates on this issue?

We have used the event log for a very long time and our customers expects to find their logging information from our products in there.

It is not an option to log directly to the Application Log since we need to provide our own manifest (and make the log appear under "Application and services logs").

[zarochi]

For what it's worth; I have the exact same issue. My ETW logging library is shared between a core app and a .Net 4.6.1 app. It works in the latter, but not the former. Perfview has only been reporting the error my app is hitting and trying to log into the event log; not the actual attempt to log to the event log.

I attached the only other exception trace that was generated that wasn't the "cannot connect to server message" my code is generating on the off-chance it's helpful.

[vancem]

cc: @vancem

Intiallly, the focus of .NET Core was on cross platform (e.g. Linux) support. Channel support (which is what we are talking about with event viewer support), is inherently a windows feature, and thus was not prioritized.

The question is should it be now (which is what this issue is asking). If the cost is low enough, that would go a long way toward 'just doing it' (since fretting about it could actually cost more). We should at least investigate what works is needed (and in particular what exactly fails in the issue logged above.

[zarochi]

That's understandable; I can see where cross platform support is much more relevant here.

Based on the workaround I put in place for now; I think some enhancements could be put into Microsoft.Extensions.Logging to accommodate the missing features if it makes more sense to focus on that library instead. I think the biggest thing is the ability to define custom events. Without a manifest my event logging adds gross extra text (super technical term there) to each event that's just annoying. There are a few workarounds for this where you create a manifest separately and point the registry to it, but I had marginal luck with those.