3

In one of my project, I need to check whether the event log "Microsoft-Exchange-ManagedAvailability/Monitoring" exists on the machine (event source is ManagedAvailability).

I used

EventLog.Exists("Microsoft-Exchange-ManagedAvailability/Monitoring")

and

EventLog.SourceExists("ManagedAvailability")

Both returns false, but the event log does exist. It is under "applications and services logs"/Microsoft/ , see screen shot.

So, how can I check whether this log exists?

Thanks

enter image description here

urlreader
  • 6,319
  • 7
  • 57
  • 91
  • My biggest question is the syntax for the event log names. I can't see anything immediately obvious in the MSDN to demonstrate how nested logs are named. I would start by iterating the existing logs ([see here](https://msdn.microsoft.com/en-us/library/74e2ybbs(v=vs.110).aspx)) to see if you can find exactly how that log is named. For example, do you need to specify that the root log folder is "Applications and Services Logs"? – Ian Jan 04 '16 at 22:47
  • The trick is that it is not an event log. Anything that is nested is via ETW. See http://stackoverflow.com/a/21012623/138200 for more information on how to read ETW Providers. – Mitch Jan 04 '16 at 23:41

3 Answers3

3

It appears that EventLog.Exists() only supports classic event logs, and doesn't support the new-since-Vista hyphenated-format-with-slash format. Process Monitor shows that it tries to open HKLM\System\CurrentControlSet\Services\EventLog\Microsoft-Exchange-ManagedAvailability/Monitoring, which doesn't exist - it's in HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-SENSE/Operational.

So I guess you'll either have to try to open and catch a failure exception (ugly), or get list of all event logs and find yours:

EventLogSession.GlobalSession.GetLogNames().Any(
    s => string.Equals(s, "Microsoft-Exchange-ManagedAvailability/Monitoring", StringComparison.OrdinalIgnoreCase))
Jonathan
  • 6,939
  • 4
  • 44
  • 61
1

Do you have appropriate permission for accessing the Event Source. For e.g. you might need administrator permissions for checking the Event Source.

From MSDN

Because this method accesses the registry, you must have the appropriate registry permissions on the local computer; otherwise, the query returns false.

EDIT1

Can you try to use following code to check what are the event logName listed on your machine. After getting the list, check if the Event logName exists or not, if it exists, pass the same name in your code for event logName.

Also, you can navigate to Event Log for which you need info (Right Click) -> Properties -> Full Name. This name should be used in Exists method.

System.Diagnostics.Eventing.Reader.EventLogSession.GlobalSession.GetLogNames()
Abhinav Galodha
  • 9,293
  • 2
  • 31
  • 41
  • The log names that the `EventLog` class can read can be found in the static [`EventLog.GetEventLogs()`](https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.eventlog.geteventlogs), on my system it lists vastly fewer logs than your `Eventing.Reader.EventLogSession.GlobalSession.GetLogNames()` and helps explain why OP cannot open their log using the `EventLog` class. – Quantic Jan 03 '20 at 17:19
1

Are you running this on a machine with User Account Control (UAC)? I just checked the MSDN page on EventLog and found this tidbit:

Because this method accesses the registry, you must have the appropriate registry permissions on the local computer; otherwise, the query returns false.

I don't know how the event log is related to the registry exactly, but I have done other work with the registry. If it's the same problem, you need to raise your execution privilege level. To do this you need to add an application manifest file to the solution, and set requestedExecutionLevel level="requireAdministrator", which means whenever you run the application on a machine with UAC it will ask "Are you sure?". You also need to ensure the project properties specify the manifest to use.

Another pitfall I hit was that when you're debugging through Visual Studio, it will run with VS execution level, not those specified in the manifest (see here). The easiest solution is to set VS to run as Administrator in the shortcut properties.

Community
  • 1
  • 1
Ian
  • 1,475
  • 2
  • 15
  • 31