Hello I am testing the new windows feature : "ETW-based visibility on Windows" (https://github.com/osquery/osquery/issues/7836). I see the following error when I try to query 'shared_resources" table after enabling "process_etw_events". Below is the output from osqueryi (version 5.8.1):

C:\Program Files\osquery>osqueryi --disable-events=false --enable_process_etw_events=true
W0320 10:04:49.862340  9200 options.cpp:106] The CLI only flag --logger_plugin set via config file will be ignored, please use a flagfile or pass it to the process at startup
Using a [1mvirtual database[0m. Need help, type '.help'

osquery> select * from shared_resources;
E0320 10:04:57.237459  9200 shared_resources.cpp:54] The following WMI query could not be constructed: SELECT * FROM Win32_Share. enum osquery::WmiError[0] (WmiRequest creation failed in ExecQuery)

Is this a bug ? Thanks Kunal

Thanks Kunal for trying the new ETW-based table! In the scenario above the

shared_resources

tables fails because of a bug in the

WmiRequest::CreateWmiRequest

WMI helper. The

shared_resources

table uses WMI to obtain the data, and WMI requests cannot be performed because of a bug in how

WmiRequest::CreateWmiRequest

helper interacts with the COM framework. The issue can be triggered if

osqueryi

calls a table that uses COM before calling

shared_resources

or any other WMI-based table. So, for example, the query below will fail because of this same problem (`windows_update_history`uses COM)

osquery> select * from windows_update_history;

osquery> select * from shared_resources;

I've described the bug in detail in #7962. I've also pushed a fix for this bug in #7963. @zwass @seph This bug exists before 5.8.0, but it can be indirectly triggered by using the ETW table. Can we consider adding the fix to a patch release in case there is one?

I approved it, and I’m game for a 5.8.2. I want to get the counter PR merged and then we’re good. See milestone

Thanks for the update @seph!