LogMonitor with named provider without GUID? about windows-container-tools HOT 10 CLOSED

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 @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

from windows-container-tools.

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.

from windows-container-tools.

Yes, it is listed, like this:

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

Yes, within container

from windows-container-tools.

@mloskot @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.

from windows-container-tools.

@mloskot -- what's the reason around not having a GUID for a custom ETW provider?

from windows-container-tools.

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. @iankingori

from windows-container-tools.

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?

from windows-container-tools.

@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 @iankingori

from windows-container-tools.

@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.

from windows-container-tools.

Thank you @bobsira and your team

from windows-container-tools.