runtime: EventLog without desktop framework installed results in "message is not found" logs in EventViewer

@danmosemsft @pakrym Can we get this issue re-opened? The original issue was not about how overly verbose the error is, but as @eightvans said, the fact that you even get it in the first place. If you configure event logging via the provided .AddEventLog() extension method, you would expect that to just work instead of misconfiguring the registry settings to point to a dll that doesn’t exist.

The problem being that if in my Program.cs I write:

WebHost.CreateDefaultBuilder(args)
.UseStartup<Startup>()
.ConfigureLogging(builder =>
{
    builder.AddEventLog(new EventLogSettings
    {
        SourceName = "MySource",
        LogName = "Application"
    });
});

The program will then create a registry setting in:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\MySource

With an EventMessageFile set to

C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.2.6\EventLogMessages.dll

Which doesn’t exist, which causes the verbose wrapping messages in the event log.

(This is with the .Net Core Hosting bundle 2.2.6 installed on Windows 10. The folder exists but not the file)

The fix I’d like to see is either EventLogMessages.dll is included in .net core at the location, or the registry entry is configured to point to something else that does exist.

Another vote for reopening. I’m in the process of porting our services to .NET Core (or making it possible to run them under .NET Core, at least) and this issue, while not a showstopper, is a blemish, and is definitely the “fault” of the framework – it relies on an EventLogMessages.dll that exists in Framework, but not Core, yet it blithely registers the event log source as if it was there anyway.

A proper fix would not be completely trivial – even adding a reference to a shared DLL from the shared directory is obviously the Wrong Thing to do if the application is supposed to be a self-contained deployment. Arguably System.Diagnostics.EventLog should add this DLL to the artifacts. Framework gets around the need for having to build a separate EventLogMessages per application by simply pre-registering all event IDs with default formatting. A fairly elegant hack, but it still needs the resource DLL to be available for Event Viewer (and other things reading the event log).

An effective if clumsy operational workaround while this is not yet there is to create a symlink for the nonexistent file to just use the one from Framework, which can be assumed to exist, e.g.:

mklink "C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.2.6\EventLogMessages.dll" "C:\Windows\Microsoft.NET\Framework\v4.0.30319\EventLogMessages.dll"

But this is not the approach CoreFX itself can take.

Most logging tools will give you a snippet of the logs when looking at an overview of logs in aggregate, if we don’t specifically write something in to strip this message off, we will see “The description for Event ID x from source y…” as the summary which actually does hinder diagnostics in practice.

Are the logging tools scraping the text from the Event Viewer window? The event log APIs do not return that message.

You actually need the c++ compiler to do this. You need to create a message file, compile the message file into a C header file and resource, and finally compile that it into a DLL.

If you have an events.res file from rc.exe, you can use csc -nowarn:CS2008 -target:library -win32res:events.res -out:events.dll and not need a C++ compiler.

Microsoft.Diagnostics.Tracing.EventRegister embeds mc.exe and rc.exe, but it is intended for manifest-based events; IIRC, those encode version numbers and other things in event identifiers, which then might not match what aspnet/Logging and other libraries write to System.Diagnostics.EventLog.

We don’t generally care or want the old windows style of formatting messages and arguments (which this message file format was built around), since we do that ourselves in dotnet.

The old Windows style has the advantage that the language of the events can be chosen by the user viewing them, rather than the software reporting them. But perhaps that is less important nowadays.

Are the logging tools scraping the text from the Event Viewer window? The event log APIs do not return that message.

The same exact message is generated by the EventLog apis: https://github.com/dotnet/runtime/blob/4f9ae42d861fcb4be2fcd5d3d55d5f227d30e723/src/libraries/System.Diagnostics.EventLog/src/Resources/Strings.resx#L186 https://github.com/dotnet/runtime/blob/3130ac980c97c0664eddb04411f8f765a9f908d8/src/libraries/System.Diagnostics.EventLog/src/System/Diagnostics/EventLogEntry.cs#L156-L167

IIRC a lot of MMC was written in .NET so it’s likely that event viewer is using the .NETFramework version of this code (which is largely copied here) to render event messages.

I’ve checked in a fix for this issue here: https://github.com/dotnet/runtime/pull/45884

Folks who are needing this or would like to try it out can pick up the 6.0 builds of EventLog and try it out.

One more vote for reopening this issue.

Creating a new event source using .NET Core, adds a registry entry that points to a file that does not exist -> C:\Program Files\dotnet\shared\Microsoft.NETCore.App\2.2.6\EventLogMessages.dll.

/cc @danmosemsft

Okay, I just came across this same issue. I think the part that is a bug is that when a new EventSource is created it references a file that does not exist. It shipped in previous desktop versions of .net but does not ship with core. When creating an EventSource the registry entry should, by default, point to a file that does exist.

Isn’t desktop framework a required windows component @pakrym? What is the configuration?

@anipik we should have a better error and probably not repeated.