none
Bug: Sysmon - <ProcessAccess onmatch="include" /> chewing 8x the CPU of no line, or line commented out ? RRS feed

  • Question

  • Hi all,

    I've done some very thorough testing and an 'empty' ProcessAccess stanza chews up 0.8% of CPU on an idle (<5% CPU) machine.  This might seem tiny, but obviously on a 'busy' machine, this could be secretly chewing up a *lot* more CPU....

    Basically, the line:

        <ProcessAccess onmatch="include" />

    Which explicitly stipulates, by being empty, that no Process Access events are to be logged, this chews up CPU a lot more CPU that leaving it to the default 'off', e.g. by deleting or commenting out the line entirely:

        <!-- <ProcessAccess onmatch="include" /> -->

    (this immediately reduced the baseline CPU from ~0.8% to ~0.1%)

    This is obviously, like any Sysmon hook, very dependent on the system it's running on, and the applications - but in my case it was a Citrix platform where CPU usage is directly proportional to cost.

    At a guess, I'd say the parser it adding a hook only when it see the stanza, but at runtime, when there are no include/excluded statements to search through it hits some weird CPU chewing area of code that is ugly.

    Any chance of a fix, or at least confirmation of "yeah, don't do that." ?

    Thanks for a great tool though - really effective ! <3


    Saturday, July 7, 2018 3:37 PM

All replies

  • I'm running into the same issue. 

    Having a problem with Sysmon CPU Load.
    I have a pretty good rig and with my config, with Event 10 enabled (Doesn't matter what it is), Sysmon process CPU jumps up from 0.5% to 5-7%.
    My other rig, which isn't as good, jumps from 0.5% to 15-20% Sysmon process CPU usage.

    When I disable this Event, it drops back down.
    Is there any particular reason this one event requires so much CPU? Or better yet, a fix, without disabling it?

    I also excluded my endpoint solution / av... by SourceImage / TargetImage... same result...

    Any ideas? Thanks in advance.

    Wednesday, October 16, 2019 6:41 PM
  • My issue was resolved by upgrading from 10.40 to 10.41..
    Thursday, October 17, 2019 1:11 PM