Just some questions about TCC "hanging" and PIDs...

[mathewsdw]

This is far from the first time this has happened, and the only solution I've found so far in some cases is just to reboot Windows. But I'd really like to know what is going on here and how I can "fix" it other than just "killing" TCC sessions or restarting Windows in the worst case (which has a lot of disadvantages related to closing everything down and saving all of my work "in progress" and so on; and I can have quite a few "works in progress" that are in active "Notepad" instances or spreadsheets or e-mails I am keeping "open" for "reference" purposes or writing or documents I am creating in MS Word or open Firefox sessions because of, simply put, my extremely bad memory and leaving such items open has no "negative" consequences at all as far as I can tell; CPU usage runs right around 50% other than "bursts" of CPU activity by (supposedly!) inactive TCC sessions, and the highest CPU usage in general is by the Windows "Magnifier" application which I very much need because of my relative blindness and I have running at "above normal" priority. And right now "physical memory" with everything but two now-killed TCC sessions is exactly 50% according to the Task Manager.

So here's the situation: First, all of my TCC sessions are running very slowly, it can take up to roughly 30 seconds when I hit the up arrow key before I see the last command I entered. Using Task Manager, I see TCC sessions that are doing absolutely nothing (i.e., they are sitting at the command prompt) using the previously mentioned "bursts" of CPU usage in the range of 60% or more for periods of more than just a second or two. And it is not atypical for a TCC session to just "hang" forever - i.e. the only way to un-hang it is to hit the "close" button (the "x") on the tab or cancel it using the Task Manager, or, again in the worst case, reboot Windows. And these "hung" TCC sessions are not typically running anything but a TCC-provided "command"; in one TCC session I just killed it was running a batch file, and the other simply "help". And I want to make it clear here: said batch file was not "caught" in a loop because said batch file had no loops. And even if it had been caught in a loop a Ctr-C or "break" should have killed it because said batch file had an active "On Break Cancel 16" statement. And said batch file ran no "programs" of any kind (not even internal commands) whatsoever and this is because I am attempting to generally replace C++ programs by batch files. And killing these TCC sessions can often be quite a loss to me because doing so "loses" all of the "history" for that session which I am quite dependent upon because of my bad memory. I tend to have five or six or even more TCC sessions open at one time; each one for a particular "task" (or "sub-task") that I am working on at the moment because the "history" is a real time-saver and quite important to me because of my bad memory. While I wouldn't go so far as to say that this a "major problem" (and actually needing to reboot only happens about once a week, I would guess) I would call this far more than a "minor inconvenience" (which I why I am taking the almost two hours so far I have used to write this posting). (By the way, I solved the question(s) about PIDs in the title of this posting while writing it. Sorry!)

- Dan

 

[rconn]

I have never experienced any problems with CPU usage or hanging for extended periods. Nor has anyone else ever reported them -- and I suspect that's the sort of behavior that would generate a lot of complaints!

All that TCC is doing at the prompt is sitting (inactive) waiting for a Windows API to signal some keyboard activity. (If that API were seriously broken Microsoft would have a few hundred million irritated users.)

Have you tried running without the (many!) plugins you're using? Do any of your plugins do anything at the prompt (i.e., not just when executing a command or variable)? AFAIK, nobody's ever run any definitive tests on whether various third-party plugins play well together.

 

[mathewsdw]

Rex, while I don't doubt you in the least when it comes to that what TCC is doing is "waiting for a Windows API to signal some keyboard activity", I also have absolutely no doubt that these bursts of CPU activity do happen for TCC sessions that are sitting at the command prompt despite my general level of incompetency. So the only possibility is as you suggest: It must be one of the plugins or interactions between the plugins. And bad memory is why, as is usual, I am loading them all. Put simply, I have found a number of very useful capabilities (particularly "SafeChars" which almost completely obviates TCC's one major limitation - again, a limitation that I understand why it exists and don't disagree with the decision(s) that you made that cause it to exist) and seeing them there on the start-up screen reminds me of them and gives me an incentive to investigate further if I need a capability that a plugin might have.

 

[rconn]

My point is that you don't know whether the plugins you're loading are bug-free and don't have any conflicts with the other plugins. (Which would not be unexpected given they're from different authors.) I'm not suggesting you stop using plugins, just that you try to find what plugin(s) causes the hangs.

There are only two possibilities to explain your observed problems:

1) An obvious and catastrophic Windows bug (that nobody else appears to be experiencing)
2) One or more plugin bugs or incompatibilities

If you don't want to try to isolate the problem, you can always resort to rebooting Windows.

 

[mathewsdw]

Rex, I'm sorry that I wasn't clear. I was explaining why I had so many plugins installed, not saying that I was unwilling to follow your advice (which could take a while given that I am so glacially slow...). - Dan