Batch file pauses for no reason

[element]

Win7 x64, TC 11. Every now and then I see a strange pause in TCC batch execution. The batch file just pauses. All I need to do to get it to move on is to hit Enter in the console window. The pauses are not disk/CPU/network related: no high activity is taking place. Since hitting Enter gets the batch going again instantly, it suggests that it's some weird console quirk. The batch file runs overnight and I don't want to waste a night due to a pause like this. So I run a script that sends Enter keystrokes to the relevant console. It's stupid, but it works.

How can I tell if it's TCC or Win console doing this? It's next to impossible to debug this since the pauses occur randomly.

 

[Kachupp]

Post the script would be a good start

> -----Original Message-----
> From: element
> Sent: Tuesday, 5 April 2011 1:25 a.m.
> Subject: [Support-t-2748] Batch file pauses for no reason

 

[element]

Post the script would be a good start

Not really. It's 490 lines of complex code and the pauses happen randomly i.e. anywhere. Where it happens in the script changes with each run (otherwise debugging it would be a snap). On a "good" night the whole batch file runs just fine, on a "bad" day you get a pause somewhere. It almost looks like an occasional, slight timing mismatch: TC runs a command, the command takes 1 sec to execute, but TC misses the "command completed" signal, so it just hangs there, waiting.

 

[rconn]

It almost looks like an occasional, slight timing mismatch: TC runs a command, the command takes 1 sec to execute, but TC misses the "command completed" signal, so it just hangs there, waiting.

That's unlikely, as it would require a monstrous Windows bug (which would be biting *everybody*).

Is this batch file running in a TCMD tab window or in a TCC console window?

 

[element]

Is this batch file running in a TCMD tab window or in a TCC console window?

TCC console. A timing bug wouldn't necessarily bite everyone if it arises only under some obscure, rare circumstances. Anyway, it's a speculation.

 

[rconn]

TCC console. A timing bug wouldn't necessarily bite everyone if it arises only under some obscure, rare circumstances. Anyway, it's a speculation.

Given the hundreds of millions of batch files run every day, it pretty much *would* bite everybody!

Anyway, there isn't any timing involved - TCC just waits for an event from Windows that the child process has ended. If the child were somehow to end before TCC started the wait, the Windows API would return an error that the process already exited. In any case, there isn't any way that TCC would want a keystroke.

Depending on your commands, it's remotely possible that you're popping up a messagebox window and the keystroke is closing that window. There's an ancient Windows bug that sometimes causes the first popup window to appear underneath the active window, so you might not be able to see it.

 

[element]

Depending on your commands, it's remotely possible that you're popping up a messagebox window

Nope, no hidden msgboxes, I checked in Nirsoft's Window Lister. If it was some command-specific msg, I'd expect it to occur on the same line in the batch file, whereas the stall can happen anywhere. I can't really debug this with breakpoints, because I can't predict where the issue will occur. Does TCC have some kind of a low-level debug mode, so that if it happens, I could examine the most recent TCC-Win communication and figure out what TCC is waiting for? I know about the "debug" directive but it's not low-level enough. I think I need to get down to the level of message traffic between TCC and Win.

 

[Charles Dye]

It sounds to me as if someone is pressing Pause or Control-S. Or Windows thinks that someone has pressed Pause or Control-S.

... Your batch file doesn't use Keystack, does it?

 

[element]

It sounds to me as if someone is pressing Pause or Control-S ... Your batch file doesn't use Keystack, does it?

No manual key presses, no keystack anything. BTW, is there a guarantee that a command line app (zip, xcopy, etc) will always report to Win when it's done? Can a command line app finish without an error, but not report this to Win?

 

[vefatica]

Far-fetched, but ... if you have QuickEdit on and left-click (perhaps inadvertently) in the console window, the batch file will continue until it's time to produce output, then stop. It will start again on any keystroke. Of course, you should see a visual indication that you are in "select" mode.

 

[vefatica]

On Mon, 04 Apr 2011 23:02:06 -0400, element <> wrote:

|No manual key presses, no keystack anything. BTW, is there a guarantee that a command line app (zip, xcopy, etc) will always report to Win when it's done? Can a command line app finish without an error, but *not* report this to Win?

No. Windows knows when apps terminate (they don't have to report it). Is it
possible that an external application is pausing, maybe with an error message or
prompt that you're not seeing for some reason (redirection?)?

 

[element]

Is it possible that an external application is pausing, maybe with an error message or prompt that you're not seeing for some reason (redirection?)?

Hm, that's an interesting thought: a warning that's directed away from the console, yet waiting for a reply. It can't be a major error because I'd have noticed if the batch didn't do its job. Next time I see a stall I'll check if it's a command line app and if it could be giving off a non-critical warning.

 

[element]

QuickEdit on and left-click (perhaps inadvertently) in the console window, the batch file will continue until it's time to produce output, then stop

QuickEdit is on, but the batch starts its own console when no one's touching the machine. I'd say a stray left-click is unlikely, but I'll double check. Thanks for the tip.

 

[element]

Hm, that's an interesting thought: a warning that's directed away from the console

FWIW, I did some investigating: no redirected warnings, but the stalled console does seem related to external command-line tools: 7-zip, erunt (old-school registry backup), maybe others. If they're called from the batch directly, like this:

7z.exe [args]

they hang 5-10% of the time (no error, no warning). Adding "start /wait" beforehand seems to fix the problem:

start /wait "7z" 7z.exe [args]

I wonder if this is somehow related to multi-threading (I'm on 8-core). Perhaps some command-line tools spawn multiple threads and confusion arises as to which thread signifies the end of the command as a whole. "start /win" works because it treats the newly spawned console as a unit (meaning all threads must be finished for the console to close). Just my theory...

 

[rconn]

I wonder if this is somehow related to multi-threading (I'm on 8-core). Perhaps some command-line tools spawn multiple threads and confusion arises as to which thread signifies the end of the command as a whole. "start /win" works because it treats the newly spawned console as a unit (meaning all threads must be finished for the console to close). Just my theory...

The code in TCC for "start /wait" and for waiting for a process to end when at the command line is exactly the same.

 

[element]

The code in TCC for "start /wait" and for waiting for a process to end when at the command line is exactly the same.

Well, "start /wait" has yet to stall on me, so I'll stick to it.

 

[Jim Cook]

This also seems unlikely, but I know there to be a bug in Windows 7 with multi-threaded apps that sometimes return the thread return code of a child thread instead of the process exit code. It doesn't seem likely that it would cause a stall, but I suppose you could have odd errorlevel testing that would manifest that way.