Does TCC know I'm visiting the forums?

[vefatica]

Or does the forum know that TCC is running?

Try this. Start a new TCC v20. Watch it for a while in TaskMgr; I see a rock solid 0% CPU. Visit the forums and log in. Go back to TaskMgr. Now I see TCC bouncing around ... 0%, 1%, 2% (occasionally 5%) CPU.

Below are more quantitative comparisons. All three are newly-started TCCs. The first is idle for 5 minutes with no browser, the second is idle for 5 minutes while visiting the forum's front page, the third is idle for 5 minutes while visiting Google. Compare the CPU figures.

v:\> wait 5m & pstat
PID:  2344
Module:  G:\tc20\tcc.exe
Started:  2016-08-27 14:04:17
Running:  5 minutes 8 seconds
User CPU:  0.0468003 sec
Kernel CPU:  0.0156001 sec
Total CPU:  0.0624004 sec (0.02%)
Working Set:  14340 KB
Virtual Mem:  12668 KB
Priority class: NORMAL
Owner:  vefatica
CommandLine:  "G:\tc20\tcc.exe"

v:\> https://jpsoft.com/forums/ & wait 5m & pstat
PID:  704
Module:  G:\tc20\tcc.exe
Started:  2016-08-27 14:10:22
Running:  5 minutes 18 seconds
User CPU:  1.0140065 sec
Kernel CPU:  7.2852467 sec
Total CPU:  8.2992532 sec (2.61%)
Working Set:  16084 KB
Virtual Mem:  12960 KB
Priority class: NORMAL
Owner:  vefatica
CommandLine:  "G:\tc20\tcc.exe"

v:\> http://www.google.com & wait 5m & pstat
PID:  3908
Module:  G:\tc20\tcc.exe
Started:  2016-08-27 14:16:50
Running:  5 minutes 2 seconds
User CPU:  0.0624004 sec
Kernel CPU:  0.0156001 sec
Total CPU:  0.0780005 sec (0.03%)
Working Set:  15660 KB
Virtual Mem:  12964 KB
Priority class: NORMAL
Owner:  vefatica
CommandLine:  "G:\tc20\tcc.exe"

 

[vefatica]

It's interesting that while I was composing my previous post, a running TCC stayed at 0% CPU. As soon as I posted it and returned to viewing the forum, it started using more CPU as described earlier.

 

[rconn]

Or does the forum know that TCC is running?

No, and no.

 

[vefatica]

No, and no.

Do you have any idea why TCC shows increased CPU usage when I'm connected to the forums? I've been watching it for about an hour now and it's utterly predictable. Here's the last 5 minutes for an idle TCC.

v:\> https://jpsoft.com/forums/ & wait 5m & pstat
PID:  3908
Module:  G:\tc20\tcc.exe
Started:  2016-08-27 14:50:09
Running:  5 minutes 5 seconds
User CPU:  1.4664094 sec
Kernel CPU:  9.2664594 sec
Total CPU:  10.7328688 sec (3.52%)
Working Set:  16100 KB
Virtual Mem:  12952 KB
Priority class: NORMAL
Owner:  vefatica
CommandLine:  "G:\tc20\tcc.exe"

 

[rconn]

I don't know, it's not reproducible here, and there's no code in TCC that can possibly do that.

Unless you've got a wacky plugin or you're running PROCESSMONITOR.

Did you try it with CMD to see if it shows the same results?

 

[vefatica]

I don't know, it's not reproducible here, and there's no code in TCC that can possibly do that.

Unless you've got a wacky plugin or you're running PROCESSMONITOR.

Did you try it with CMD to see if it shows the same results?

I'm not running PROCESSMONITOR. It's the same with no plugins loaded. I also watched CMD and a few other running apps; none but TCC showed this behavior.

 

[rconn]

If the effect actually exists (I have my doubts), it is absolutely, positively, not being caused by any code in TCC.

You may have a third-party app (or even Windows) injecting code into TCC.

 

[vefatica]

It doesn't happen when the Browser is IE.

 

[rconn]

It doesn't happen when the Browser is IE.

So it's a bug/feature in FireFox?

 

[vefatica]

So it's a bug/feature in FireFox?

If it is, you might be a little concerned since FireFox would then seem to be targeting your product!

 

[rconn]

When TCC is waiting for input, this is what it's doing:

        if (( GetNumberOfConsoleInputEvents( hInput, &dwPending ) == 0 ) ||  ( dwPending == 0 )) {
            // hack for VM bug in WaitForSingleObject eating CPU
            Sleep( 20 );
            continue;
        }
        ReadConsoleInput( hInput, &irBuf, 1, &dwInputEvents );

So - TCC calls Windows to see if there are any keyboard events. If there are, it calls ReadConsoleInput and waits for Windows to return the character. If there aren't, it sleeps for 20ms and tries again. There is nothing -- absolutely nothing -- here that can be affecting or be affected by a browser running in another session. (Unless you've reverted to Windows 3.1 and cooperative multitasking?)

If FireFox is injecting code to bollix up either of those Windows APIs, then it's even more horrible than previously suspected and you should run far, far away from it. (Well, you should run far away from FireFox for a host of other reasons as well ...)

 

[vefatica]

OK, I'll try something else. I want it to start fast, be single-instance, not require any other EXEs, do embedded PDFs, remember credentials, and simply display stuff correctly. I'm wary of anything from Google ... those folks who want to get as much information about me as possible. But if you think Chrome will fit the bill, I'll try it.

What are your recommendations?

 

[vefatica]

Here's another good one. Before going out for dinner, I started TCC. When I returned I saw

v:\> pstat
PID:  1536
Module:  G:\tc20\tcc.exe
Started:  2016-08-27 17:31:47
Running:  1 hour 49 minutes 26 seconds
User CPU:  0.0156001 sec
Kernel CPU:  0.0780005 sec
Total CPU:  0.0936006 sec (0.00%)
Working Set:  15756 KB
Virtual Mem:  13552 KB
Priority class: NORMAL
Owner:  vefatica
CommandLine:  "G:\tc20\tcc.exe"

After 6 minutes connected to the forums, I saw

v:\> pstat
PID:  1536
Module:  G:\tc20\tcc.exe
Started:  2016-08-27 17:31:47
Running:  1 hour 55 minutes 33 seconds
User CPU:  0.1716011 sec
Kernel CPU:  1.7004109 sec
Total CPU:  1.8720120 sec (0.03%)
Working Set:  15772 KB
Virtual Mem:  13568 KB
Priority class: NORMAL
Owner:  vefatica
CommandLine:  "G:\tc20\tcc.exe"

That is, total CPU was multiplied by about 20 in those 6 minutes!

 

[rconn]

Not reproducible here.

The only way this could happen is if something in your system was sending large amounts of keyboard input and/or mouse events to TCC. TCC is entirely at the mercy of the Windows APIs.

 

[vefatica]

I'm only reporting what I see. I wish I could explain it.

 

[rconn]

OK, I'll try something else. I want it to start fast, be single-instance, not require any other EXEs, do embedded PDFs, remember credentials, and simply display stuff correctly. I'm wary of anything from Google ... those folks who want to get as much information about me as possible. But if you think Chrome will fit the bill, I'll try it.

What are your recommendations?

Two questions:

1) Since you've chosen for years to configure the slowest possible system (32-bit Windows & FireFox), why is "start fast" now important?
2) Why is "single-instance" and "not require any other EXEs" of any significance? Are you running DOS / Win 3.1?

 

[vefatica]

Two questions:

1) Since you've chosen for years to configure the slowest possible system (32-bit Windows & FireFox), why is "start fast" now important?
2) Why is "single-instance" and "not require any other EXEs" of any significance? Are you running DOS / Win 3.1?

1. I didn't exactly choose it; it's what I have. It's mostly satisfactory. Until about 6 months ago I could push a button and by the time I started typing, Google was ready to accept my input. But FF slowed down. Chrome starts a little faster but I still have to wait.
2. That's with should be called a pet peeve. I think of it as poor design (like the 3000+ character command line that one of those instances of Chrome has). I like to know what's going on in my computer. For years I've had a PowerPro icon on my desktop that shows me how many processes are running. I am always aware of it. In NT4 it was 13 with an empty desktop ... 18 in XP ... 28 in Windows 7. I reckon it'll be pushing 40 in Windows 10.

Hoping I'm wrong, I don't expect to be amazed by how fast 64-bit Windows is.

 

[vefatica]

How many processes does Edge need?

 

[Bob Chapman]

If FireFox is injecting code to bollix up either of those Windows APIs, then it's even more horrible than previously suspected and you should run far, far away from it. (Well, you should run far away from FireFox for a host of other reasons as well ...)

What browser or browsers work well with TakeCommand and would be good alternatives?

 

[vefatica]

So - TCC calls Windows to see if there are any keyboard events. ...

It's not that thread. ProcessExplorer shows 3 threads in TCC using CPU.

The first of those is the one whose CPU usage ... seems out of line initially and increases when I visit the forum. When I suspend it (with ProcessExplorer) CPU usage at idle remains down around 0.06% regardless of what I do. And TCC does not seem to suffer from it's suspension (though I haven't done a lot of testing). Of the other two threads shown above one is TCC's input thread, and the other (seemingly) polls the TCC.EXE class window.

So (curious as usual) what is that thread, and why does it do so much?

 

[vefatica]

Of the other two threads shown above one is TCC's input thread, and the other (seemingly) polls the TCC.EXE class window.

That part of my analysis was a little off (inconsequentially). One of those threads doesn't poll the TCC.EXE window; it is (apparently) that window's window thread.

 

[Joe Caverly]

 

[nikbackm]

I also have the AllocDup thread consuming CPU in TCC, but it's always active, does not matter if Firefox is running or not.

In your case, would TCC start consuming more CPU if you visit another HTTPS site than the forums in Firefox? Or maybe another site using the same forum software? Surely it's not only jpsoft.com causing this effect.

 

[vefatica]

I also have the AllocDup thread consuming CPU in TCC, but it's always active, does not matter if Firefox is running or not.

In your case, would TCC start consuming more CPU if you visit another HTTPS site than the forums in Firefox? Or maybe another site using the same forum software? Surely it's not only jpsoft.com causing this effect.

Other sites do it, some don't; the JP forums seems like a worst case. And FireFox and Chrome do it equally. I don't know another that uses xenForo. That thread is always running here, too. But it's CPU usage goes up when I visit the forums. Do you see that? I have tried like heck to find TCC actually doing something (WinDbg, ProcessMonitor) and I haven't been able to do so. It's very odd that other processes would affect TCC's CPU usage.

 

[vefatica]

Here are two more striking observations.
Around 11:00 this morning, I started two instances of TCC, pid 3380, the first below running the thread mentioned in previous posts, and pid 764, the second below, with that thread suspended. I hid them so I would neither use them nor close them. Through the next 4.5 hours I RD'd from work to home and checked the forums with Chrome, closing Chrome each time. When I left my office for my last class at 3:30, the comparison looked like this.

v:\> echos Thread:^t^t & pstat 3380 | grep Total & echos No Thread:^t & pstat 764 | grep Total
Thread:         Total CPU:      51.6675312 sec (0.33%)
No Thread:      Total CPU:      0.0936006 sec (0.00%)

At that time, I left Chrome running, with me logged in, in a thread showing me as logged in with the radiating green circles.

When I got home it was about 7:30 and the comparison looked like this.

v:\> echos Thread:^t^t & pstat 3380 | grep Total & echos No Thread:^t & pstat 764 | grep Total
Thread:         Total CPU:      587.3593651 sec (1.89%)
No Thread:      Total CPU:      0.0936006 sec (0.00%)

Figuring that those logged-in indicators might be a pretty reliable indication that something strange was going on, I left Chrome in that state for 10 minutes, and saw this change; look at the times.

v:\> echo %_time & echos Thread:^t^t & pstat 3380 | grep Total & echos No Thread:^t & pstat 764 | grep Total
19:30:14
Thread:         Total CPU:      591.1969897 sec (1.89%)
No Thread:      Total CPU:      0.0936006 sec (0.00%)

v:\> echo %_time & echos Thread:^t^t & pstat 3380 | grep Total & echos No Thread:^t & pstat 764 | grep Total
19:40:08
Thread:         Total CPU:      611.9139225 sec (1.92%)
No Thread:      Total CPU:      0.0936006 sec (0.00%)

That's 20 seconds of CPU in 10 minutes, or about 3.33% CPU ... with TCC idle!

So I'm still wondering what the heck is going on, and, if it's not deliberate, can anything be done about this very peculiar interaction between apparently independent processes.

FWIW, I tried to find other processes that were affected as TCC is ... without success.

Note that Chrome itself is quite a CPU hog!

PID:            2524
Module:         C:\Program Files\Google\Chrome\Application\chrome.exe
Started:        2016-08-31 14:48:22
Running:        5 hours 28 minutes 42 seconds
User CPU:       2547.8707324 sec
Kernel CPU:     912.4030487 sec
Total CPU:      3460.2737811 sec (17.55%)

 

[vefatica]

The forums were down for about 30 minutes earlier tonight. When they came back online, all the mysterious stuff I had been observing had stopped. My test TCC, running hidden since 11:00 this morning, the one with the thread under discussion intact, that thread having amassed over 700 seconds of CPU through the day, has added only 3 clock ticks (~0.047 sec) in the ~2 hours since the forums came back online.

Please enlighten us, Rex. What does that thread do and how did visiting a web site cause it to do so much?

 

[vefatica]

Hmmm! The behavior is back again. I'm totally mystified.

 

[nikbackm]

Other sites do it, some don't; the JP forums seems like a worst case. And FireFox and Chrome do it equally. I don't know another that uses xenForo. That thread is always running here, too. But it's CPU usage goes up when I visit the forums. Do you see that? I have tried like heck to find TCC actually doing something (WinDbg, ProcessMonitor) and I haven't been able to do so. It's very odd that other processes would affect TCC's CPU usage.

No, the having the forums opened or not makes no visible difference for me.

I have Windows 10 x64 at home and there the AllocDup thread (in every TCC instance) takes about 1,6% CPU.

At work we have Windows 7 x64 and there the AllocDup thread takes 0,2% CPU. I just noticed though that when I have Firefox open (with a few tabs I am currently reading) then the CPU use for the AllocDup thread (in every TCC instance) goes up to 0,26% CPU. Maybe the same happens at home as well, but there the base CPU use is already so high (due to Windows 10 telemetry perhaps ;) ) that I haven't likely noticed so far.

I use TCC v15 both at home and at work.

 

[rconn]

There are three permanent threads in TCC:

1) The main processing thread
2) A thread to handle messages posted to the TCC console window (required because Windows will not pass messages to console sessions)
3) A thread to poll the monitoring functions

You're apparently having problems with #3 -- but all it does is sleep for 25 milliseconds, then wake up and check to see if any monitoring conditions have been triggered. If so, it processes them; if not, it goes back to sleep for another 25 milliseconds and tries again.

There are additional threads that may be created, mostly for specific monitoring actions (like EVENTMONITOR or FOLDERMONITOR), or some very short duration ones for some internal commands.

Assuming that you don't have any monitoring going on, then something (external to TCC) is screwing with the Windows timer.

 

[mdlawler]

So Rex, are you saying that the thread that process Explorer says starts at

There are three permanent threads in TCC:

1) The main processing thread
2) A thread to handle messages posted to the TCC console window (required because Windows will not pass messages to console sessions)
3) A thread to poll the monitoring functions

You're apparently having problems with #3 -- but all it does is sleep for 25 milliseconds, then wake up and check to see if any monitoring conditions have been triggered. If so, it processes them; if not, it goes back to sleep for another 25 milliseconds and tries again.

There are additional threads that may be created, mostly for specific monitoring actions (like EVENTMONITOR or FOLDERMONITOR), or some very short duration ones for some internal commands.

Assuming that you don't have any monitoring going on, then something (external to TCC) is screwing with the Windows timer.

Rex, is this an example of thread #3 in TCC I see this thread in Process Explorer

TID CPU Cycles Delta Start Address
9464 0.84 254,604,930 TakeCmd.dll!AllocDup+0x2e0

Is that that thread? If I have a program that changes the Windows high resolution timers would that cause this? Does this thread use SetTimer to control itself? Could you create a debug version that would allow those of us having this issue to test your theory? Also I have this thread in TCMD

TID CPU Cycles Delta Start Address
9112 0.29 89,826,290 tcmd.exe!CPUUsage+0x17596b

What is this thread doing and I assume nothing can be done to lessen it's CPU usage?