Turns out that the problem was the

chrome_extensions

table, and disabling that table in the flags file stopped the CPU from being pegged. Any idea what might be causing this? Disabling this table also stopped fleet from gathering all the installed programs on the server, even though chrome is not installed. Keep in mind that this is on domain controllers only, and this wasn't a problem on other windows servers that don't have chrome installed.

Are there other Chrome-based browsers installed on those systems? For example, Edge browsers

Nope. only internet explorer

What happens when you run

select * from chrome_extensions

from osqueryi on that DC?

Running

select * from chrome_extensions;

spikes the CPU temporarily while the query is run (for about 10 seconds). OS is Windows Server 2016.

I think the problem here is what @defensivedepth was mentioning earlier, with the fact that a DC is a bit special around users. Basically all the users that are known to the DC will be visible to osquery; depending on the number of users, listing them starts to become costly. This is a known issue and

chrome_extensions

will walk through all the users present in the DC to find those extensions, if you don’t provide a

uid

constraint. I’m working on a change for how users and groups are retrieved from the system on Windows, so that the cost of retrieving that information is distributed over a longer period of time, by keeping a cache, which then massively speeds up the queries, especially if the constraints used are on index columns (

uid

on the

users

table,

gid

on the

groups

one and so on)

Hey @Stefano Bonicatti. Is there an issue # or some other way that I can track your work in this area?

Hi @User, I’ve just opened a PR here: https://github.com/osquery/osquery/pull/7516

Awesome, thanks!