TeaTimer & Page Faults

[hiballer]

I have been looking at reasons why my computer has been acting "jerky" at times and found that Program Manager shows TeaTimer as having around 150 to 200 Page faults A SECOND! Since my computers run 24/7, and I have Spybot on all of them, this count can build up to 15 or 20 Meg right fast.

Mem usage will climb up also, but at a slower rate.

Is this normal?

Bill

[hiballer]

OK. Failing an answer for that, is there anyone that can tell me why TeaTimer will climb up in memory usage from a cold start at about 5,400K to over 127,480K in just 24 hours? Just what the heck is it checking? And, Why does it need that much memory to do it?

Bill

[hiballer]

Anyone? I can hear you breathing! Is this a memory leak? Can it be stopped short of killing TeaTimer and restarting it about every 8 hours or so?

Bill

[PepiMK]

Anyone can use the srearch function

Do you know what page faults exactly are? Take a look at Wikipedia, for example

For the memory usage, you could try the new beta, there has been a small leak (and over time those can grow) fixed, but page faults... some parts of Windows (svchost.exe, wmiprvse.exe etc.) have many millions of page faults here; the Yahoo Widget engine has dozens of millions of those. All that indicates is swapping...

[noel-pr7]

hiballer, what version of Tea Timer do you have when you were experiencing these "page fault" problems?

also, what version of Windows do your computers use?

as PepiMK suggested, try testing out the Spybot S&D Tools 1.5 beta which includes version 1.5 beta of Tea Timer.

[hiballer]

Yes, I DO know what page faults are. My first training in computers was in 1963, taught Computer Programming and Maintenance in the USN for four years, and I have been in IT ever since that time. I have never heard of a "srearch" function (but I know what you mean ). Playing with the Virtual Memory settings will slow the page faults, but not stop them. Throwing more RAM into the machine has the same effect. I am suprised that a program whose function is to just monitor changes to the Registry and a few other settings would need to continuously swap out memory (paging).

All 4 of my computers are using WinXP Pro SP2 with all patches, updates, and corrections from M$.

I have the new Beta, but haven't applied it as of yet to any of the computers. I am hoping that the memory leak has been addressed.most of my new installations take place after backups on Friday.

TeaTimer (under the context menu of Properties) shows as 1.4.0.2 in File Version, but Product Version is 1.4.0.3.

Thanks for the input.

Bill

[hiballer]

I've applied the Beta version to one of my computers. The steady increase in memory required by TeaTimer is still present. The page fault counter still goes up, but, perhaps, not quite as fast. The memory leak appears not to have been fixed.

I left TeaTimer alone on one of my computers for over a week. The memory required (according to Program manager) when first started was 15,257 K. By the end of the week it had grown to 517,342 K.

As a temporary solution I have written a script that runs once a day at 0300 and kills TeaTimer then restarts it. This appears to be the only way I can keep the memory leak at bay.

Thanks to all for their help.

Bill

[bitman]

Do you have any other process monitor applications operating on that PC?

During the early testing of TeaTimer (Spybot 1.3) it was discovered that multiple process monitor applications could interact and cause the memory usage of TeaTimer to climb, possibly related to the page faulting common to all such applications, since this was also affected in some cases.

There's really nothing wrong with Page Faults in such a case and they're actually quite common with such monitoring applications. The problem comes about when multiple applications attempt to monitor the same events, with potential conflicts as a result and the "memory leaks" a possible side effect. These aren't really a memory leak in the classic sense, they're allocations made by one application that become locked by another, with the same end result.

We were never able to explain a small number of these, though I suspect all were related to another monitoring application, but the user was unaware of the true situation on thier PC. Possibly with your background you'll be able to discover the root cause and identify what's been missed up until now.

Bitman

[hiballer]

Thanks Bitman. That might prove to be the case. I'll have to investigate that route more thoroughly. There should be some root reason why this is happening because, as I said, there should be no inflation of TeaTimer's base memory for no good reason. Page locking from two or more applications competing for the same memory space would account for the apparent "leak".

I wonder if this could be related to some sort of interrupt issue - as in an interrupt handler interrupting between pages.

I'll check on this - may be a while as I will be out of town for two weeks.

Bill

[PepiMK]

I've found where exactly those page faults do appear - inside a Microsoft function we call

We do free the memory allocated by this call correctly afterwards... at least according to their documentation It's funny though that the documentation for Windows CE on the same function tells one to NOT use this general cleanup afterwards, but use a special cleanup call. Now Windows CE is something different, but I wonder if they've detected this problem while porting functions to Windows CE but never reported it back to the core team or whatever

I've found a workaround - tested successfully on XP, but I still have to test it down all other versions now.