My machine was running like a dog (Woof! Woof!) So going into the task manager to see what was going on, CPU utilization was 100% and there were 16 instances of TCC (and of, course, conhost) running. The problem is that I only had 4 active TCC sessions going (three in one Take Command session, another one in a different Take Command session, and a single instance in a third Take Command session that was running Administratively). So I used SystemInternal's pskill command to kill all instances of TCC (and their associated Take Commands and conhosts also died) and my system is actually useable again (why I'm even able to type this posting). Now I will be the first to admit that Task Manager showed that collectively they were using less than 10% of the CPU, but killing them all fixed the problem, and 10% was strange because after killing them all total CPU utilization went down to about 60%. What is going on here?
A minor complaint...
- Thread starter mathewsdw
- Start date
- Aug
- 2,033
- 82
Hi,
Not sure of a solution to your problem, but TCC has the internal TASKEND command, which allows you to kill running tasks similar to pskill.
Code:
End the specified process.
TASKEND [/F] pid | name | "title"
/F(orce close)
pid : process ID
name : process name
"title" : window titleJoe
Thank you, Joe. I was (barely) aware of the "TaskEnd" command, but I've used PSKill for years and have been able to put it on company machines that I, of course, didn't own because it was free. The only advantage that "TaskEnd" might have is being slightly faster since it is an internal command, but I seriously doubt that it would be enough to notice. (And I just timed it, 1 execution of TaskEnd took 0:00:00.00 seconds, TaskEnd being too fast to even measure it, and 1 execution of PSKill took 0:00:00.02 seconds, and I think that you would agree that that's imperceptible human beings. To get a more "accurate" picture, 100 invocations of TaskEnd took 0.57 seconds, 100 invocations of PSKill took 1.76 seconds, or to say it another way TaskEnd is almost exactly three times faster than is PSKill. And PSKill is from a "reliable" source, Microsoft "absorbed" SystemInternals some number of years ago.)
- Dec
- 236
- 2
If you were a the limit of physical memory because of all the tcc processes running (tcc has a fairly large virtual size), then you may have got into swapping pages to disk or worse page thrashing where one copy of tcc would swap in a page just to have it swapped out by the next copy of tcc to take controll of the CPU. Since page swapping is handle by the system, the CPU usage would not appear in relationship to tcc. You may have seen 10% of TCC and 50% of system page swapping.
Thank you for the above information, it makes sense as far as it goes (it still doesn't explain why there were so many running TCC instances in the first place).
And in a more realistic comparison of PSKill (the previous really wasn't because the program was being read out of the system disk cache rather than the physical hard drive after the first run of the 101 runs), 100 instances of TaskEnd took (in this particular test, numbers could vary somewhat because of other system activity) .68 seconds. 100 executions of PSKill actually being read off of the hard disk (never mind the ugly way I had to force this unless you are interested, the proof that my ugly way did the job is in the numbers) too 5.40 seconds, meaning that TaskEnd is almost 8 times faster than is PSKill. However, a single execution of PSKill took only .054 seconds, not a real long time to wait. (It is distinctly possible that the cache(s) actually in the hard disk/hard disk controller is reducing the time by some amount, but I really don't think that the amount of time it takes is really an issue, nor do I know of any way to clear the cache in the hard drive and/or controller. Note also that those times include the time taken for the programs to write their output to the screen, if that is eliminated (by redirecting the output to NUL: ) it takes .6 seconds for TaskEnd and 1.76 seconds for PSKill making TaskEnd about 3 times faster.)
And in a more realistic comparison of PSKill (the previous really wasn't because the program was being read out of the system disk cache rather than the physical hard drive after the first run of the 101 runs), 100 instances of TaskEnd took (in this particular test, numbers could vary somewhat because of other system activity) .68 seconds. 100 executions of PSKill actually being read off of the hard disk (never mind the ugly way I had to force this unless you are interested, the proof that my ugly way did the job is in the numbers) too 5.40 seconds, meaning that TaskEnd is almost 8 times faster than is PSKill. However, a single execution of PSKill took only .054 seconds, not a real long time to wait. (It is distinctly possible that the cache(s) actually in the hard disk/hard disk controller is reducing the time by some amount, but I really don't think that the amount of time it takes is really an issue, nor do I know of any way to clear the cache in the hard drive and/or controller. Note also that those times include the time taken for the programs to write their output to the screen, if that is eliminated (by redirecting the output to NUL: ) it takes .6 seconds for TaskEnd and 1.76 seconds for PSKill making TaskEnd about 3 times faster.)
rconn
Administrator
- May
- 13,184
- 205
Staff member
The only way to get all those zombie TCC sessions is if your Take Command sessions were killed in an unusual fashion (i.e., from the Task Manager or from another app). That will leave anything running in a tab window as an invisible but still active console session.
samintz
Scott Mintz
- May
- 1,590
- 27
Dan, I don't know if PsKill uses similar technology to other SysInternals apps. But if it does, then it supports both 32 and 64 bit environments. The 32 bit app contains the 64 bit app as an attached resource. So part of the startup dance is determining whether it is running on a 64 or 32 bit OS. If it is a 64 bit OS, it extracts the 64 bit app and launches it. Then cleans it up when it is complete.
TaskEnd, on the other hand, is built-in to TCC. So there is no extra overhead when running that command. I am not at all surprised by the timing differences. As you said, when running it on one or two processes, it really isn't possible to see those timing difference though.
-Scott
TaskEnd, on the other hand, is built-in to TCC. So there is no extra overhead when running that command. I am not at all surprised by the timing differences. As you said, when running it on one or two processes, it really isn't possible to see those timing difference though.
-Scott
- Aug
- 2,033
- 82
I think that I have run into this before when I have *messed around*.
My solution was to click on Tabs -> Attach Tabs... to see the invisible, but still active console sessions. This way, they became usable again, and I did not have to kill them using TASKEND.
Is this what you are talking about, Rex?
Joe
Thank you for an explanation, Rex. Your explanation was good news. However, your explanation reminded of what exactly had happened, and that's one bit of bad news in a whole list of bad news. The worst news that will "color" everything that follows is my bad memory, I really don't remember the details of what went on and therefore can't tell you about a rather serious problem I encountered.
So where did all of the "orphan" TCC sessions come from? Simple: I was doing something that killed the current (and I believe all running, although I'm not sure because of my bad memory) instances of TCMD.exe. I was tempted to report it as a bug, but at the time I was actually trying to accomplish something so I didn't report it immediately and I no longer remember exactly what I was doing that was killing TCMD sessions, leaving behind the "orphan" TCC sessions. (I hadn't realized that it was just Take Command that was dying leaving behind all of those orphan TCC sessions. )
So there's evidently a rather serious bug of some kind in TCMD.exe, but I no longer remember the details of how to invoke it. Sorry.
So I'll get back to the issue of PSKill vs. TaskEnd. First I'll start out that I have no issue(s) with TaskEnd, it's just that I don't use it purely out of habit. And invoking PSKill is, it turns out, a lot slower than is TaskEnd in real-world situations, but that doesn't matter because I don't ever use it in a batch file and it's more than fast enough for a human being (me).
Details: It takes .0074 seconds per task-kill attempt (I arrive at this figure by doing 3 sets of 100 task-kill attempts in a row, timing them, and averaging the times). If I redirect all of the output of TaskEnd to nul (>&NUL ) those figures don't change significantly, somewhat surprisingly to me. In that situation it takes TaskEnd an average of .0073 seconds to kill a task). For PSKill, it's an average of .3131 seconds under the same circumstances with output going to the screen, and .2818 seconds for the same circumstances with output going to nul. This makes TaskEnd 41.31 times faster than PSKill with output going to the screen, 36.6 times faster with output going to nul:
Now I want to point out what the difference between these figures and the numbers I reported above is: using another (really, really ugly) way I forced PSKill to be reloaded from the disk in such a way that no cache made any difference at all, not the Windows disk cache, not any cache that might be in the hard drive controller, and not any cache in the physical disk drive itself; i.e. absolutely no caching of any kind. And since it had to be read into memory directly from disk on every invocation, it's obviously much slower.
But I will note that I won't notice a third of a second when running PSKill from the command line.
So where did all of the "orphan" TCC sessions come from? Simple: I was doing something that killed the current (and I believe all running, although I'm not sure because of my bad memory) instances of TCMD.exe. I was tempted to report it as a bug, but at the time I was actually trying to accomplish something so I didn't report it immediately and I no longer remember exactly what I was doing that was killing TCMD sessions, leaving behind the "orphan" TCC sessions. (I hadn't realized that it was just Take Command that was dying leaving behind all of those orphan TCC sessions. )
So there's evidently a rather serious bug of some kind in TCMD.exe, but I no longer remember the details of how to invoke it. Sorry.
So I'll get back to the issue of PSKill vs. TaskEnd. First I'll start out that I have no issue(s) with TaskEnd, it's just that I don't use it purely out of habit. And invoking PSKill is, it turns out, a lot slower than is TaskEnd in real-world situations, but that doesn't matter because I don't ever use it in a batch file and it's more than fast enough for a human being (me).
Details: It takes .0074 seconds per task-kill attempt (I arrive at this figure by doing 3 sets of 100 task-kill attempts in a row, timing them, and averaging the times). If I redirect all of the output of TaskEnd to nul (>&NUL ) those figures don't change significantly, somewhat surprisingly to me. In that situation it takes TaskEnd an average of .0073 seconds to kill a task). For PSKill, it's an average of .3131 seconds under the same circumstances with output going to the screen, and .2818 seconds for the same circumstances with output going to nul. This makes TaskEnd 41.31 times faster than PSKill with output going to the screen, 36.6 times faster with output going to nul:
Now I want to point out what the difference between these figures and the numbers I reported above is: using another (really, really ugly) way I forced PSKill to be reloaded from the disk in such a way that no cache made any difference at all, not the Windows disk cache, not any cache that might be in the hard drive controller, and not any cache in the physical disk drive itself; i.e. absolutely no caching of any kind. And since it had to be read into memory directly from disk on every invocation, it's obviously much slower.
But I will note that I won't notice a third of a second when running PSKill from the command line.