Misc handles and such

Started by edkiefer, June 24, 2016, 04:19:03 PM

Previous topic - Next topic

edkiefer

Quote from: Jeremy Collake on June 24, 2016, 03:55:47 PM
I long ago optimized the rate of process handle opening to fix a previous interoperability issue with some security software that hooked all process opens to evaluate them. This reduced the rate of handle re-opens (which are normally rapid anyway, when not intercepted) by several orders of magnitude. Once per process instance, instead of once per second per process instance.

Somehow, this old report, despite long being fixed, caused an MB mod to conclude, after seeing a few process opens (which Process Lasso does since it manages processes!), that the fault must be with Process Lasso, despite no such problem occurring without the presence of MBARW!

Then the thread was closed. So, that's that. I can guarantee you that I spend extraordinary efforts to make Process Lasso as optimal as possible, but can't speak for whatever security software hooks do when they start blocking requests for inspection. We don't have any reason to suspect that process handle open frequency is the problem here, but it was taken as such, and the thread immediately closed without evidence of such.
When I said memory/handles I was talking in general, not specific to PL, but some issue when all these products ar run.
I will say this after testing many A/V type products on Win10, there are some odd system load that happens (I am comparing to a Win7 system).

The Win10 "seems" because they have many more back-ground services but are set to manual(app triggered) you tend to get spikes, though not bad and not high, but none the less there. If you montor processes you see this aggressive on/off of processes.
You don't notice to much any performance degradation "but" with A/V is does get worse compare to default (Win10 Defender).

This is just something I noticed, running back to back A/V programs and clean Win10, I have no real data just seat of pants type report.
Bitsum QA Engineer

Jeremy Collake

Ed, I want to keep this thread on-topic, so I'm going to move your post - please take no offense.
Software Engineer. Bitsum LLC.