Kill or close 100 CMD windows being opened in squence

Question

I'm doing an operation that will open 100 Dos windows in sequence (one after the other is finished).

Each window will take approximately 2 hours to complete the process, then the next window starts, and so on.

I would like to close each right after it starts. Is there any way I can automate the process of closing the dos windows?

UPDATE: I'm running a software that opens a DOS window to perform an operation, upon opening the DOS window the software writes a batch file. This will happen about 100 times because I setup the software to perform 100 different operations. I'm going to use all 100 batch files later. I need to automate the closure of the DOS windows. I don't really need those windows, I only care for the batch files being written. Hope this clarifies the issue.

Answer 1

If you're using GOTO EOF at the end of your scripts that are executed, you can simply replace that with EXIT /B instead and that should work for your need.

Example Script

@ECHO ON 
SET RootDir=C:\Folder

FOR /F "TOKENS=*" %%A IN ('DIR /S /B "%RootDir%\*.bat"') DO START "" "%%~A"
EXIT /B

---

EXIT

Quit the current batch script, quit the current subroutine or quit the command processor (CMD.EXE) optionally setting an errorlevel code.

Syntax

EXIT [/B] [exitCode]

Key

/B        When used in a batch script, this option will exit 
          only the script (or subroutine) but not CMD.EXE

exitCode

          Sets the %ERRORLEVEL% to a numeric number.
          If quitting CMD.EXE, set the process exit code no.

_source

Answer 2

There are multiple possible approaches, including alternate solutions.

Will you have any other "command prompt" windows open that you care about? If not, open up a new command prompt and kill all the command prompt windows:

TASKKILL /fi "imagename eq cmd.exe"

Alternatively, why have 100 windows created? As Vinayak's comment noted, that may not be needed. Consider making one batch file that uses the CALL command multiple times. e.g.:

@Echo Off Call File1.bat Call File2.bat Call File3.bat

If you are trying to run all this simultaneously instead of sequentially, the start command may be useful. Consider:

@Echo Off Start CMD /C File1.bat Start CMD /C File2.bat

Notes: * Perhaps especially if using the START command, you're best off if you are careful with PATHs. So, don't just run "File1.bat" if "File1.bat" is not in your PATH or your current directory. Whenever creating a new window, I am in the habit of not trusting that I start in the current directory I think I do. That may involve using the CD command more often (perhaps even more often than necessary, just to be safe). Or, many commands can be run from other directories if you specify the full path. e.g.:

@Echo Off Start CMD /C %USERPROFILE%\mybats\File1.bat Start CMD /C %USERPROFILE%\mybats\File2.bat

If you have a "space" character in your directory/folder names, you may need to surround the entire path with quotation marks.

@Echo Off Echo My home directory is %USERPROFILE% Pause Start "" CMD /C "%USERPROFILE%\mybats\File1.bat" Start "" CMD /C "%USERPROFILE%\mybats\File2.bat"

• If you need to use quotation marks in your START command, be careful. The START command has surprised many people by treating the first set of quotation marks as characters that have a special meaning: setting a window title. That is why the above examples show a set of quotation marks before the paths.
• I am writing this answer based on memory/knowledge. I haven't tested this when writing this answer, primarily because I couldn't think of a very useful test that would apply well to your task, because I'm not fully understanding your task. However, 100 batch files, times two hours a piece, is 8 days 8 hours. So i highly recommend spending several minutes testing your approach (with some simple/test batch files) before launching your over-week-long event.
• Older versions of Windows have sometimes had some funny limits, perhaps especially when using features designed to provide some compatibility with the older MS-DOS code which was even more filled with funny limits. Microsoft has improved this situation by remedying many DOS-related quirks as time marched on. However, I'd question if 100 simultaneous windows might break something, in at least some versions of Windows. You are advised to be careful, and not rely on the results of untested procedures. (If you have no prior results, the proper procedure is to do a smaller task that is easy to test, and make sure you thoroughly test things before relying on the results.) I realize such ideas may seem obvious, and I realize that actually testing stuff may be harder in practice than theory, but I point this out because such procedures are often so important that they are worth mentioning anyway.

Good luck.