robocopy cancelling batch file processing

May 30, 2008
I have a set of (.BTM) batch files that I use to update offline copies of my working directories that use the robocopy program. The top level batch files call a common batch file to perform the work in a uniform way. I have noticed that occasionally batch processing terminates prematurely. I have attempted to work around the issue by looping until a flag is set in both the common batch file and the top level batch files, the looping code never gets a chance to continue the processing because it acts like a cancel command was encountered. If I manually rerun the top level batch file it will typically run normally but it may also terminate at another point in the processing.

I recently modified my common batch file to enable command echoing just before running robocopy and got lucky when the issue occurred when synchronizing the first directory. The invocation of robocopy completed and the batch file continued running to next two statements which were on break and a return. At this point the batch file processing was cancelled with a call, 3 gosubs, an iff , and another gosub pending.

This issue occurs on multiple different PCs. All of the PCs are currently running Windows 10, but if I remember correctly the issue also occured under Windows 7. The working directories are on the C: drive and the offline mirror copies are on USB 3.0 drives (SSD or magnetic).

The common batch file can perform the processing using either robocopy or the builtin TCC copy command. I have never seen this issue occur with the copy command but robocopy is about 10 times faster than the copy command.
Last edited:
May 20, 2008
Syracuse, NY, USA
I don't know how an external EXE (robocopy) could cause a batch file to terminate unless the batch file were somehow cooperating. Can you give more information?
May 30, 2008
I've noticed a similar issue when using TCC 20 on Windows 10.

Often the batch file just stops prematurely after a ROBOCOPY command completes even though there are many more ROBOCOPY calls left in the file. No error messages are output.

IF you re-run the batch file then it always continues successfully after the ROBOCOPY call where it stopped last time. Probably because there are no changes to copy, and no output from robocopy to display. But a subsequent robocopy call can stop batch processing instead. So just continue re-running until all robocopy calls are completed, lol.

The batch file just calls robocopy directly and does not check the error code from it, no other batch files are called.

This only happens with TCC 20, I also have TCC 15 and there the problem never occurs with the same batch file, same Windows 10 and same computer.

I would guess it has something to do with ANSI processing myself, but have never taken the time to investigate, easier to just re-run the file when not complete.

I attached a simplified version of the batch file.


  • generic_backup.btm
    567 bytes · Views: 95


Jul 6, 2008
Have you tried using the START command vs CALL with the ROBOCOPY line?
That should remove any interaction with your batch file.
Apr 2, 2011
North Carolina, USA
From the CHM help file:


Purpose: Execute one batch file from within another.

You do not want a batch file to run from the BTM - you want a EXE to run. Have you looked at the DEFER command?

Purpose:Execute a command after the batch file exits

Format:DEFER command


A batch file can have multiple DEFER commands. They will be executed in first in, first out order when the batch file exits.

If you have variables on the DEFER command line, they will be expanded before the DEFER command is processed, not when command is executed. To delay variable expansion until command is executed, use single back quotes around the variable names, or double the %'s before the variable names.

If the last argument on the line is a single (, it is interpreted as the beginning of a command group. DEFER will append the following lines (in a batch file) or prompt you for more input (at the command line) until it gets a closing ).

May 30, 2008
I cannot use START since I want the batch file to wait for ROBOCOPY to complete. START will open it in a new separate console and the batch file will continue to the next robocopy directly.

Yes, I can agree that CALL is unnecessary here as an unqualified ROPOCOPY call will run robocopy.exe on my current system.

I often use CALL from batch files anyway, in case I would have a batch file with the same name as the command, in that case a direct call would replace the current batch file, while with CALL it will continue from the current line afterwards.

Haven't seen that using CALL would ever have hurt when used to run executables and aliases.
(Keep in mind that this works fine in TCC 15)

But sure, could test without it next time I use the batch file.
May 26, 2008
Don't use START... or if you do, use START /WAIT. But that is completely unnecessary. Just run robocopy.exe directly with nothing preceding it!
May 30, 2008
Just tested it again with CALL removed.

And what do you know, the problem totally disappeared, everything went through at the first attempt!

So problem solved on my part, thanks for the suggestions everyone!

Apparently the robocopy process somehow returned the CANCEL "code" at times causing the batch processing to end even though it was not a batch file. Guess it happened to work in TCC15 due to different internal implementation details.
Aug 23, 2010
I cannot use START since I want the batch file to wait for ROBOCOPY to complete. START will open it in a new separate console and the batch file will continue to the next robocopy directly.
START "" /B ... will run in the same console and will be nearly identical to DEFER with exception that your batch file will continue after spawning the task, not before.
Be aware that it might mess the screen, if backgrounded task wold output anything.
May 30, 2008
Has anyone noticed that that ROBOCOPY is unusual in that it modifies the window title. I have not found any other external program that modify the window title.

I have continued to periodically debug this problem and have determined that it only happens when returning from a subroutine that invokes ROBOCOPY, with the RETURN command being treated like a CANCEL command. Until today, I was never able to consistently reproduce the problem.

While working on another batch file I encountered a situation that always causes the batch file to terminate early. The batch file uses a subroutine to process one directory at a time using ROBOCOPY. The subroutine generates the source and destination directory names from a GOSUB parameter and other environment variables, invokes ROBOCOPY, and then returns. When encountering the return statement the batch file always terminates (like the return is a CANCEL statement). I determined that if I add a WINDOW command (WINDOW "") to set the window title to the default, the return works correctly with execution continuing after the GOSUB command.

Starting with this new batch file, I created a minimized batch file that consistently reproduces the error with my files. I then enhanced the minimized batch file so that it could create test files, but have not been able to generated a set of test files that will recreate the problem.

Hopefully this additional information (ROBOCOPY modifying the window title causing a RETURN command being treated as a CANCEL command) will enable JP Software to be able to find the root cause.
May 30, 2008
Wrapping the ROBOCOPY calls in @exec[] finally fixed this problem for me.

(The removal of CALL I wrote about earlier in the thread did not help after all)