TeaTimer CPU load after startup thoughts

[PepiMK]

Since many people ask about it, we gave the issue some thoughts as to what could be done about this:

1. We could display it's acitivity; if it is showing which process it is scanning, that might make it more understandable.
2. We could remember which files have already been scanned (hash of files) and thus "skip" known ones; would have to clear this cache after each update though since new updates might lead to different results.

Thoughts please

[md usa spybot fan]

PepiMK (Patrick):

To start with, perhaps just an explanation of what TeaTimer is doing when it first starts would help.

For example:

Right now I have 53 processes running and if my Avira Antivir's "Active Processes" scan count is correct those 53 processes are using 2144 files (exe, dll, etc.).

If I run my cursor over the TeaTimer system tray icon I see:

• 88292 processes blacklisted.
• 283740 known rating available.

If I were to restart TeaTimer would it compare the 2144 files against the list if 88292 blacklisted processes, the 283740 rated processes, both or are there other things TeaTimer is doing?

[PepiMK]

You're right, a quick overview might be helpful
Those 283740 ratings are those entries from the RunAlyzer database that are of use here (e.g. LSPs are not monitored by TeaTimer, so they're not in the list). These are loaded from TTLassh.sbs.

For each new, changed or deleted registry item, the lassh (hash sum of various of its properties) is calculated, and looked up in this list.

While this includes the MD5 of an associated file, that is very quick, and lookup of the created lassh in a hash table returns a result immediately as well. So this part doesn't take user-noticable time.

The 88292 processes are gathered from the regular detection databases, read from all .sbi files found (if you create your own, that would be more or less those File and DownloadFile rules as described on the OpenSBI wiki, though file paths etc. would be disregarded).

TeaTimer tests every new process it finds against this database of 88292 items, and when you start TeaTimer, it will regard every running process as such a new process. In your case, that would mean those 53 processes, not those 2144 which probably includes both loaded modules and file handles.

As for the speed, this is very similar to what thw new SDFiles.exe is doing, which is slow I have to admit. The changes appearing in 1.6 were mostly to reduce memory usage. By pre-organizing the data in memory, scans per file would be faster, but memory usage would increase. Keeping the in-memory database means slower per-file scans (I'm also thinking on various ideas how this could be improved).

[milius.net]

hello,

yes, please do so - the more visible information the user gets, the more are we able to find out, report & repair (system) errors ... (if any)


---
in my case: (that's why I came here today :-) )
my system resets / windows crashes without warning whenever teatimer starts - I don't know why yet, but it's everytime I start teatimer manually (it's already taken out of autostart / system start for observation)

once I saw some kind of message: "you have more then 1083 files in temp" or something - then a count down (pretty fast) then my system crashes / resets again ...

I do NOT say that teatime is the result of my system crashes - I had teatimer running before without any probs - but this time (only) it's different ...
it could be some systemfile or virus and teatimer causing some kind of chain-reaction with the anti-virus software or something like this - anyways:

it would be nice to see what files are getting checked by the teatimer so I can find out what file is causing that trouble ...
(spybot 1.6 - winxp sp3)

[wyrmrider]

Millus
you seem to have a different problem
start a new thread
also post what AV and firewall you run
do you or did you have any older AV or anti spyware installed
did your machine come pre installed with a suite or AV?

run CCleaner to clean up those temp files

appreciate your comments on this topic

[md usa spybot fan]

PepiMK (Patrick):

Thank you for the explanation.

Both proposed enhancements have merit. The first would allow people to see that TeaTimer was actively scanning during startup and the second should reduce the startup time/utilization except immediately after updates.

I can't think of anything else except possibly ordering the blacklisted processes and doing a binary lookup if it is not already being done.

[wyrmrider]

Is anyone surprised that T-timer is actually doing its job?

There may be other ways to slice the baloney but for now
you want resident protection- you get protection

you want to clean up afterward then turn it off
ps
other Antispyware programs with resident protection take even longer

you could also run Win Patrol (or similar) which would monitor and tell you something has already infected your system and maybe able to reverse the action
does not have the "lag"

(I run Win Patrol ALSO, IN ADDITION TO A real time Anti Spyware protector)

you could also run System Safety Monitor, a virtual machine, Process Guard or similar

All trade offs and all approaches open to discussion

[129260]

PepiMK (Patrick):

To start with, perhaps just an explanation of what TeaTimer is doing when it first starts would help.....

Ya, how about a notification balloon, like when you install avast antiviruis, it shows the balloon and does a box pop up that explains what stuff is, so that you know what the icon is and what it does. I think that would be the best option so that people would understand teatimer better upon first install of spybot. If md spybot fan meant something else, then oops, but I think something like i suggested would be a good way to understand teatimer.

[129260]

I feel really dumb. I read that thread so fast haha, i misunderstood what milius.net meant. I read that thread and that got me onto showing more teatimer information. Disregard my above reply lol.

[Zer0 Voltage]

@wyrmrider: Perhaps you should fully familiarize yourself with the problem reports and history before making any assumptions. This is a case of obvious abnormalities, not a need for trade-offs or alternatives and most certainly not some baloney case of TeaTimer doing its normal job. This is a case of TT needing a fix for a real and verifiable problem.

First, on some systems, the TeaTimer process NEVER recovers. It jumps to 99% on start/restart and stays there. Period. Not for a few minutes. Not for a few hours. Permanently - at least until forced closed the hard way.

On other systems, it jumps to 99% usage at boot and stays there for [at least] a few minutes, but then it does recover. But such a long spike shouldn't even be needed for truly normal activity in the first place.

And unfortunately, until it recovers or is killed, an affected system is unusable because of the CPU flood.

Other programs with resident protection DO NOT take even longer. On systems where this problem exists, every other real-time solution works fine - only TT is showing spikes.

Of further significance is that these problems were introduced during the beta period. These problems were not always present. I know because I originally reported a similar (and likely related) TT crash problem here:

http://forums.spybot.info/showthread.php?t=30453#7

and it was only after that got fixed that the CPU spike issues began. In fact, as I said then, there were no similar TT problems up until RC2 (or maybe RC1). The original problem was not present in beta 1 and 2 and the spikes didn't occur until a fix was put in place for the reported TT crash.

This all seems to be of rather critical importance to any potential resolution...

So what changed in TT between beta 2, RC1, and RC2?

And perhaps since this also never occurred before 1.6, what is TT doing now that it didn't do in 1.5.x?

Once we define what changed, the logical test is to then disable whatever changed and see if the problems persists.

At the very least, a way of displaying - or preferably logging - all TT activity would also be useful (as Patrick suggested). Trying to do that with something like Process Monitor just got too out of hand (generating 50+ Megs of data every few seconds).

I am somewhat skeptical that this will come down to "normal" behavior, however, since on nearly identical systems with the same software and configuration different levels of the problem can occur - plus, like I said, the problem didn't occur with the betas.

FYI, when TT does do something it is supposed to do, it does not spike - even on affected systems. It has a brief but normal resource increase, but that's it. I can only make a permanent spike [at will] by fully exiting and then later restarting it (at least on some systems). Further FYI, I have no TEMP files (auto-scrubbers in place) and usually <40 processes running. So anything TT does should be unnoticeable and instant (which truly normal "doing its job" TT behavior is).

Anyway, thanks very much for continuing to look into this PepiMK. If you need me to help test anything or provide any other details, please just let me know. I may not be available much now though.

Sorry if I posted any redundant info here, but evidently while I was away some people decided to start multiple separate threads for the same related issue...