EventLog.Exists returns false for some event logs

[dhhoang]

Description

Using EventLog.Exists on a log such as "ForwardedEvents" or "Setup" return false, event though those logs are available on the machine.

Configuration

• Which version of .NET is the code running on? .NET 5
• What OS and version, and what distro if applicable? Windows 10 2020H2
• What is the architecture (x64, x86, ARM, ARM64)? x64
• Do you know whether it is specific to that configuration? No, it is not.
• If you're using Blazor, which web browser(s) do you see this issue in? N/A

Regression?

Unsure

Other information

It looks like EventLog.Exists looks for information in the registry, which cannot detect the existence of non-classical logs.

EventLog.Exists return false on all logs with IsClassicLog=false attribute, according to https://devblogs.microsoft.com/scripting/use-powershell-to-review-the-setup-event-log/ .

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.

[dhhoang]

Is there any updates on this issue?
One way to implement this correctly would be to use the implementation of Get-WinEvent: https://github.com/PowerShell/PowerShell/blob/master/src/Microsoft.PowerShell.Commands.Diagnostics/GetEventCommand.cs
I can create a PR for this if this is confirmed to be the expected behavior

[Anipik]

Are you running with appropriate permissions ?

https://github.com/PowerShell/PowerShell/blob/master/src/Microsoft.PowerShell.Commands.Diagnostics/GetEventCommand.cs

No, thats not the correct way. if there is a bug that would likely be related to the underlying windows api.

[dhhoang]

Are you running with appropriate permissions ?

https://github.com/PowerShell/PowerShell/blob/master/src/Microsoft.PowerShell.Commands.Diagnostics/GetEventCommand.cs

No, thats not the correct way. if there is a bug that would likely be related to the underlying windows api.

Yes I tried to run as Admin. EventLog.Exists returns false for logs such as PowershellCore/Operational or OpenSSH/Operational.

I don't believe that this is a bug but more like an issue about where the API looks for event logs. From the code (https://github.com/dotnet/runtime/blob/main/src/libraries/System.Diagnostics.EventLog/src/System/Diagnostics/EventLog.cs)
it seems like the API simply consider the set of keys in "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog", which doesn't contain said logs.

[Anipik]

Yes I tried to run as Admin. EventLog.Exists returns false for logs such as PowershellCore/Operational or OpenSSH/Operational.

are these logs present in the registry ? if yes we can expose a new api which can take path to the key as in input as well

[dhhoang]

I did a registry search and did not find these keys in the registry.
The physical location of these logs are at C:\WINDOWS\System32\winevt\Logs\

[Anipik]

The physical location of these logs are at C:\WINDOWS\System32\winevt\Logs\

Then these wont be found by eventlog apis

[Robo210]

.Net has two sets of Event Log APIs - one for the NT 3-through-XP era and since-deprecated OpenEventLog/ReportEvent APIs (System.Diagnostics.EventLog), and one for the newer Evt* APIs (System.Diagnostics.Eventing.Reader).

The legacy APIs can only interact with classic channels, and the only method of enumerating the classic channels (without using the newer APIs) is to enumerate HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog (note: not every subkey under there is a channel, and some keys are ACLed much more strongly than others). The EventLog class, since it is using these legacy APIs, is working as intended by only scanning these registry keys. I do not recommend trying to extend this class with new APIs, because it is built on a bad foundation and already has a 15 year old replacement (frankly, if the class was just straight up removed the world would be a better place).

The modern APIs can interact with any channel type, and the method of enumerating the channels is through EvtOpenChannelEnum. This is what anybody writing code after 2005 should be using.

When it comes to the Powershell cmdlets, get-eventlog is built around the legacy APIs, and get-winevent is built around the modern APIs.

Accessing the files in C:\Windows\system32\winevt\logs when the Event Log service is running is never safe.

[dhhoang]

.Net has two sets of Event Log APIs - one for the NT 3-through-XP era and since-deprecated OpenEventLog/ReportEvent APIs (System.Diagnostics.EventLog), and one for the newer Evt* APIs (System.Diagnostics.Eventing.Reader).

The legacy APIs can only interact with classic channels, and the only method of enumerating the classic channels (without using the newer APIs) is to enumerate HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog (note: not every subkey under there is a channel, and some keys are ACLed much more strongly than others). The EventLog class, since it is using these legacy APIs, is working as intended by only scanning these registry keys. I do not recommend trying to extend this class with new APIs, because it is built on a bad foundation and already has a 15 year old replacement (frankly, if the class was just straight up removed the world would be a better place).

The modern APIs can interact with any channel type, and the method of enumerating the channels is through EvtOpenChannelEnum. This is what anybody writing code after 2005 should be using.

When it comes to the Powershell cmdlets, get-eventlog is built around the legacy APIs, and get-winevent is built around the modern APIs.

Accessing the files in C:\Windows\system32\winevt\logs when the Event Log service is running is never safe.

@Robo210 Thanks for providing the context.
I think that's okay now that we are aware of it, we can use the newer API to interact with event logs and we can close this issue. I personally think it'd be better if the API has documentation to indicate this behavior. The only documentation I could find about it right now is a 9 year-old blog.