LogMonitor with named provider without GUID?

[mloskot]

This is a feature request to allow access to log equivalent to this

Get-WinEvent -ProviderName "My.Custom.Service.1.2.3"

I have a custom Windows service and I can use that PowerShell cmdlet to access the logs.

However, if I feed the LogMonitor with the following bit in my LogMonitorConfig.json:

{
  "type": "ETW",
  "eventFormatMultiLine": false,
  "providers": [
    {
      "providerName": "My.Custom.Service.1.2.3",
      "level": "Information"
    }
  ]
}

then it complains about the invalid provider:

[2022-07-29T14:24:36.000Z][LOGMONITOR] ERROR: Invalid providers.

I read the source code and I see it is probing every named provider for GUID

windows-container-tools/LogMonitor/src/LogMonitor/EtwMonitor.cpp

Lines 129 to 155 in 83bcc98

	for (auto provider : Providers)
	{
	if (provider.ProviderGuidStr.empty())
	{
	if (!provider.ProviderName.empty())
	{
	wstring providerName(provider.ProviderName);
	transform(
	providerName.begin(), providerName.end(),
	providerName.begin(),
	towlower);
	providersWithoutGuid[providerName] = (provider);
	}
	}
	else
	{
	ValidProviders.push_back(provider);
	}
	}
	//
	// Return now if there aren't providers that need to obtain theirs GUID.
	//
	if (providersWithoutGuid.empty())
	{
	return status;
	}

It would be nice to allow logs access by named providers only, without GUID.

[profnandaa]

Mateusz Łoskot (@mloskot) -- what's the reason around not having a GUID for a custom ETW provider?

[mloskot]

As in my example above, I install a simple custom Windows service (no installer, no GUIDs, etc.) and I can access its logs with this very simple command:

Get-WinEvent -ProviderName "My.Custom.Service.1.2.3"

Why not to make LogMonitor offer similar simple access, I'm wondering.

[profnandaa]

Dug through the code further and found out that the GUID is required by the API in evntrace.h, it's not optional.

#if (WINVER >= _WIN32_WINNT_VISTA)
EXTERN_C
ULONG
WMIAPI
EnableTraceEx (
    _In_ LPCGUID ProviderId,
    _In_opt_ LPCGUID SourceId,
    _In_ TRACEHANDLE TraceHandle,
    _In_ ULONG IsEnabled,
    _In_ UCHAR Level,
    _In_ ULONGLONG MatchAnyKeyword,
    _In_ ULONGLONG MatchAllKeyword,
    _In_ ULONG EnableProperty,
    _In_opt_ PEVENT_FILTER_DESCRIPTOR EnableFilterDesc
    );
#endif

// ignore my previous comments
// following up on providerWithoutGuid map in code.

/cc. Ian King'ori (@iankingori)

[profnandaa]

QQ, is your custom provider listed here when you run:

Get-WinEvent -ListProvider *

I'm also assuming that your initial Get-WinEvent command, you are running it within your container right?

[mloskot]

Yes, it is listed, like this:

Name     : My.Custom.Service.1.2.3
LogLinks : {Application}
Opcodes  : {}
Tasks    : {}

Yes, within container

[bobsira]

Mateusz Łoskot (@mloskot) The Get-WinEvent cmdlet gets events from event logs, including classic logs, such as the System and Application logs. The cmdlet gets data from event logs that are generated by the Windows Event Log technology and events in log files generated by Event Tracing for Windows (ETW).
Get-WinEvent reads from ETW from a file and not from a provider name. Get-WinEvent source

Side notes on why we require GUID for ETW events take a look at this guide ETW

Unless you have any more concerns, we will go ahead and close this.

cc Ian King'ori (@iankingori)

[kevpar]

As an aside, there is a standard transformation that many ETW tools do to convert a name into a GUID. This allows users to specify a friendly name and have the conversion to GUID be consistent across many tools. While I don't think this would specifically solve Mateusz Łoskot (@mloskot)'s problem, it could still be useful to support.

Details: https://docs.microsoft.com/en-us/archive/blogs/dcook/etw-provider-names-and-guids
Sample conversion code (Go): https://github.com/microsoft/go-winio/blob/main/pkg/etw/provider.go#L97-L127

[mloskot]

bob sira (@bobsira) Thank you for the explanation. I don't have anything to add here and, sadly, nothing to contribute. You're an expert here and I take your points, so please feel free to close it.

[bobsira]

Mateusz Łoskot (@mloskot) Kevin Parsons (@kevpar)

An update is that we already have the feature of monitoring for logs without specifying the GUID as long as you have a valid provider name, and the provider is also a registered manifest-based event. Example configuration below would work fine:

{
  "LogConfig": {
    "sources": [
      {
        "type": "ETW",
        "eventFormatMultiLine": false,
        "providers": [
          {
            "providerName": "Microsoft-Windows-WLAN-Drive",
            "level": "Information"
          }
        ]
      }
    ]
  }
}

Code to the logic implementation

We'll update our docs to show it is possible to monitor ETW logs with only Provider Name and without the GUID.

The reason you were getting invalid providers error is because LogMonitor could not find a GUID associated with the provider's name you specified when it was looping through the list of provider names and their GUIDs in the system.

These can probably be classified as event logs and not ETW logs.