Event Log message is not shown in the way it is sent

greatvovan commented 2 years ago

Description

Messages sent to Event Log as per the documentation do not look as expected.

Instead of the string supplied to EventLog. WriteEntry() verbatim, user sees the following:

The description for Event ID <id> from source <source> cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

If the event originated on another computer, the display information had to be saved with the event.

The following information was included with the event:

<message>

The message resource is present but the message was not found in the message table

The problem seems very old and well-known. The root cause is the value set in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\log4net EventLog\EventMessageFile registry key. After creating a source with the standard means it is set into C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.6\EventLogMessages.dll. Navigating to this folder, I see that EventLogMessages.dll is just missing.

Strictly speaking, it is not that .NET spoils the message, but it does not provide all the required dependencies for that to work.

There is another issue #27742 which is marked as fixed, but the problem now reproduces. I cannot reopen #27742, so I am filing a new issue.

Reproduction Steps

Take a Windows Machine.
Install .NET 6.0.6.
Run the code (first line requires admin permissions to succeed):

EventLog.CreateEventSource("foobar", "Application");
EventLog myLog = new EventLog("Application");
myLog.Source = "foobar";
myLog.WriteEntry("42");

Then look at the recent entry in "Application" event log.

Expected behavior

The message is shown exactly as sent.

Actual behavior

The useful content is surrounded by loads of the boilerplate text.

Regression?

This definitely worked in .NET Framework and according to #27742 was fixed in .NET Core (did not check).

Known Workarounds

Pre-create the source in the Registry:
- by applying a .reg file;
- by registry editing tools (regedit.exe, cmd tools, etc).
Modify the value of EventMessageFile key after creation by EventLog.CreateEventSource().
Create a soft link file from the configured path to the real path.

As .NET Framework is included in the recent versions of Windows, there is a version of EventLogMessages.dll that is guaranteed to exist in C:\Windows\Microsoft.NET\Framework\v4.0.30319 and that can be used as a correct path in the methods above.

Configuration

Which version of .NET is the code running on?

> dotnet --list-runtimes
Microsoft.AspNetCore.App 6.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
Microsoft.NETCore.App 6.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.WindowsDesktop.App 6.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

What OS and version, and what distro if applicable? Windows 10 Enterprise 21H2

What is the architecture (x64, x86, ARM, ARM64)? x64

Do you know whether it is specific to that configuration? I don't know

Other information

Fix suggestion: include proper EventLogMessages.dll into distribution of .NET and store it at the expected path.

dotnet-issue-labeler[bot] commented 2 years ago

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

danmoseley commented 2 years ago

@ericstj as he did the original change and perhaps can recall useful context here.

ghost commented 2 years ago

Tagging subscribers to this area: @tommcdon See info in area-owners.md if you want to be subscribed.

Issue Details

### Description Messages sent to Event Log as per the [documentation](https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.eventlog?view=dotnet-plat-ext-6.0) do not look as expected. Instead of the string supplied to `EventLog. WriteEntry()` verbatim, user sees the following: > The description for Event ID `` from source `` cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. > > If the event originated on another computer, the display information had to be saved with the event. > > The following information was included with the event: > > `` > > The message resource is present but the message was not found in the message table The problem seems [very old and well-known](https://stackoverflow.com/questions/3412463/description-for-event-id-from-source-cannot-be-found). The root cause is the value set in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\log4net EventLog\EventMessageFile registry key. After creating a source with the standard means it is set into C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.6\EventLogMessages.dll. Navigating to this folder, I see that EventLogMessages.dll is just missing. Strictly speaking, it is not that .NET spoils the message, but it does not provide all the required dependencies for that to work. There is another issue #27742 which is marked as fixed, but the problem now reproduces. I cannot reopen #27742, so I am filing a new issue. ### Reproduction Steps 1. Take a Windows Machine. 2. Install .NET 6.0.6. 3. Run the code (first line requires admin permissions to succeed): ``` EventLog.CreateEventSource("foobar", "Application"); EventLog myLog = new EventLog("Application"); myLog.Source = "foobar"; myLog.WriteEntry("42"); ``` Then look at the recent entry in "Application" event log. ### Expected behavior The message is shown exactly as sent. ### Actual behavior The useful content is surrounded by loads of the boilerplate text. ### Regression? This definitely worked in .NET Framework and according to #27742 was fixed in .NET Core (did not check). ### Known Workarounds 1. Pre-create the source in the Registry: - by applying a .reg file; - by registry editing tools (regedit.exe, cmd tools, etc). 1. Modify the value of EventMessageFile key after creation by `EventLog.CreateEventSource()`. 1. Create a soft link file from the configured path to the real path. As .NET Framework is [included](https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/versions-and-dependencies) in the recent versions of Windows, there is a version of EventLogMessages.dll that is guaranteed to exist in C:\Windows\Microsoft.NET\Framework\v4.0.30319 and that can be used as a correct path in the methods above. ### Configuration **Which version of .NET is the code running on?** ``` > dotnet --list-runtimes Microsoft.AspNetCore.App 6.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] ``` **What OS and version, and what distro if applicable?** Windows 10 Enterprise 21H2 **What is the architecture (x64, x86, ARM, ARM64)?** x64 **Do you know whether it is specific to that configuration?** I don't know ### Other information Fix suggestion: include proper EventLogMessages.dll into distribution of .NET and store it at the expected path.

Author:	greatvovan
Assignees:	-
Labels:	`area-System.Diagnostics`, `untriaged`
Milestone:	-

ericstj commented 2 years ago

Can you share a repro project? Your repro steps left out the type of project you created, and the package references you added.

EventLog isn't part of the base .NET product, it's only part of ASP.NET. ASP.NET includes the System.Diagnostics.EventLog.Messages.dll which fixes this.

My best guess of what's going on is that you've built a .NET 6 project, but you're pulling in an old version of System.Diagnostics.EventLog through a transitive package reference. If that theory is correct, make sure you're referencing the latest System.Diagnostics.EventLog package to get the fix linked here.

ghost commented 2 years ago

This issue has been marked needs-author-action and may be missing some important information.

ericstj commented 2 years ago

I noticed that there does appear to be a regression in WindowsDesktop around this: in 5.0.0 Microsoft.WindowsDesktop.App included System.Diagnostics.EventLog.Messages.dll but that is absent from 6.0 and 7.0. Adding a package reference to System.Diagnostics.EventlLog should workaround it, but we should get WindowsDesktop fixed.

I'd still like to hear from @greatvovan about the scenario he's hitting this with before moving this issue.

ghost commented 2 years ago

Tagging subscribers to this area: @dotnet/area-infrastructure-libraries See info in area-owners.md if you want to be subscribed.

Issue Details

### Description Messages sent to Event Log as per the [documentation](https://docs.microsoft.com/en-us/dotnet/api/system.diagnostics.eventlog?view=dotnet-plat-ext-6.0) do not look as expected. Instead of the string supplied to `EventLog. WriteEntry()` verbatim, user sees the following: > The description for Event ID `` from source `` cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer. > > If the event originated on another computer, the display information had to be saved with the event. > > The following information was included with the event: > > `` > > The message resource is present but the message was not found in the message table The problem seems [very old and well-known](https://stackoverflow.com/questions/3412463/description-for-event-id-from-source-cannot-be-found). The root cause is the value set in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\log4net EventLog\EventMessageFile registry key. After creating a source with the standard means it is set into C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.6\EventLogMessages.dll. Navigating to this folder, I see that EventLogMessages.dll is just missing. Strictly speaking, it is not that .NET spoils the message, but it does not provide all the required dependencies for that to work. There is another issue #27742 which is marked as fixed, but the problem now reproduces. I cannot reopen #27742, so I am filing a new issue. ### Reproduction Steps 1. Take a Windows Machine. 2. Install .NET 6.0.6. 3. Run the code (first line requires admin permissions to succeed): ``` EventLog.CreateEventSource("foobar", "Application"); EventLog myLog = new EventLog("Application"); myLog.Source = "foobar"; myLog.WriteEntry("42"); ``` Then look at the recent entry in "Application" event log. ### Expected behavior The message is shown exactly as sent. ### Actual behavior The useful content is surrounded by loads of the boilerplate text. ### Regression? This definitely worked in .NET Framework and according to #27742 was fixed in .NET Core (did not check). ### Known Workarounds 1. Pre-create the source in the Registry: - by applying a .reg file; - by registry editing tools (regedit.exe, cmd tools, etc). 1. Modify the value of EventMessageFile key after creation by `EventLog.CreateEventSource()`. 1. Create a soft link file from the configured path to the real path. As .NET Framework is [included](https://docs.microsoft.com/en-us/dotnet/framework/migration-guide/versions-and-dependencies) in the recent versions of Windows, there is a version of EventLogMessages.dll that is guaranteed to exist in C:\Windows\Microsoft.NET\Framework\v4.0.30319 and that can be used as a correct path in the methods above. ### Configuration **Which version of .NET is the code running on?** ``` > dotnet --list-runtimes Microsoft.AspNetCore.App 6.0.6 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.6 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App] ``` **What OS and version, and what distro if applicable?** Windows 10 Enterprise 21H2 **What is the architecture (x64, x86, ARM, ARM64)?** x64 **Do you know whether it is specific to that configuration?** I don't know ### Other information Fix suggestion: include proper EventLogMessages.dll into distribution of .NET and store it at the expected path.

Author:	greatvovan
Assignees:	-
Labels:	`area-Infrastructure-libraries`, `regression-from-last-release`
Milestone:	7.0.0

greatvovan commented 2 years ago

Thanks everyone for your feedback. Let me provide an update on this topic.

I was not quite accurate on repro steps. Originally I encountered the problem when trying to log from EventLogAppender of log4net. It turned out that "netstandard" version of log4net does not include EventLogAppender due to portability reasons, so I used a community package called "Log4Net.Appenders.NetCore" which is supposed to provide the missing class. This package pulled System.Diagnostics.EventLog v4.5.0 as a dependency (the original package has been unmaintained for quite a long time).

I did not realize that System.Diagnostics.EventLog is not a part of the standard library. Instead of logging through log4net, I tried to use System.Diagnostics.EventLog class and got the same (mis)behaviour, so I filed this issue after my experiment.

After updating package System.Diagnostics.EventLog to version 6.0.0 (latest a.t.m.) for newly created sources value EventMessageFile of the registry key becomes C:\Windows\Microsoft.NET\Framework64\v4.0.30319\EventLogMessages.dll, which is exactly the fix I suggested. It does not solve the problem for already created sources (e.g. with old versions), but I think, this is expected, because the key and the string value are written at the moment of source creation.

TL;DR: there was probably a problem in System.Diagnostics.EventLog v4.5.0 which sneaked into my project, but the most recent version of this package seems to behave correctly.

ViktorHofer commented 2 years ago

I noticed that there does appear to be a regression in WindowsDesktop around this: in 5.0.0 Microsoft.WindowsDesktop.App included System.Diagnostics.EventLog.Messages.dll but that is absent from 6.0 and 7.0. Adding a package reference to System.Diagnostics.EventlLog should workaround it, but we should get WindowsDesktop fixed.

Thanks @ericstj for noticing and reporting the regression. This was fixed via https://github.com/dotnet/runtime/pull/72280. Is there anything else that this issue tracks or should we close it?

EDIT: Also, https://github.com/dotnet/runtime/pull/72809 tracks servicing the change in 6.0.x

greatvovan commented 2 years ago

Just a heads up regarding the latest comment from @ViktorHofer that mentions System.Diagnostics.EventLog.Messages assembly.

Please note that there is no mistake in assembly names in the problem statement of this issue. Two assemblies involved in sending messages to Event Log are System.Diagnostics.EventLog, and EventLogMessages. The former is creating the registry key and putting the reference to the DLL with a mapping table (when running EventLog.CreateEventSource()); the latter is having this mapping table. The first library must put a correct path, and the second one must just exist at that path.

I am not sure what is the designation of System.Diagnostics.EventLog.Messages and in which scenarios it is important. The fix #72280 might be necessary in general, but I am not sure it is relevant to this ticket and am asking to validate my thinking.

When using the recent version 6.0.0 of System.Diagnostics.EventLog assembly from the eponymous package by Microsoft/dontetframework the issue is not reproducible as it sets reference to .NET Framework version of EventLogMessages (which is guaranteed to exist unless .NET Framework is discontinued and excluded from Windows), so maybe there is no problem as per the original description. The main question is whether it is the right choice to reference .NET Framework library from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\, OR maybe another version of EventLogMessages (mapping) must be included into distribution and referenced by System.Diagnostics.EventLog, but I do not know the answer and leave it to you to decide since you better understand design considerations.

dotnet / runtime