tldr: ran a batch file with only 1 line in it: echo ^ . This file eats 70-100% of one core and approx. 1k RAM a second...???

While answering this question, I came across some odd behavior in Windows batch files.

I was having some batch file fun to show the OP that you could have a ^ at the end of a line in a batch file for line continuation, example:

file test.bat:

echo How are ^
you today ^
my good fellow

Would output: How are you today my good fellow

I was curious if the command prompt would display a More? from the batch file similar to the command prompt if you just had a line like so in a batch file: echo Do you want some ^

If you did that on the command line it would display More? (as for more input):

C:\>echo Do you want some ^

However, I tried this line (having ONLY this line) in a batch file and some unexplainable behavior happened, so I played around with the script to find that the only time this happens is when an echo statement is the last line and the ^ is the last character of the batch file.

A quick file to reproduce:

file test.bat:

echo ^

Running that batch file on my 64-bit Windows 7 machine ate up 70-100% of one of my cores and would eat roughly 1k of memory every second!!

Running this file also ignored all input (except CTRL+ key presses to end it), though after the file ended the input was still flushed to the console:

(nothing is happening here except CPU/RAM eating)
(I would proceed to type something like "HELLO")
CTRL+C (script ends)
'HELLO' is not recognized an internal .....

My 'search-foo' (Stack Oveflow, Stack Exchange, MSDN, Google and Bing) turned up no results that could explain this odd behavior in a batch file (only what the ^ does on command line and batch files); I would think that if the only line in a batch file was echo ^ it would just end the script and not run until I CTRL+C out of it?

Has any one else noticed this behavior or could explain what might cause this? As well could that lead to any possible avenues of attack on a system?

It's not a major issue (I don't have any batch files that end in echo ^) but it struck me as very peculiar that 1 line of batch results in 1k/s??

(Side note: I'm going to try this same situation out through some programming languages [.NET, Java and C/C++] and some web scripts (JS maybe?) to see what happens as a result)

  • Interesting. Does it here on my Win 8.1 32-bit machine as well. Its like you're telling it to continue the echo with the contents of the next line, but there is no next line, so it gets confused. Strangely(?) if you type in something while it's "hung", hit enter, and then hit ^C 1-5 times, the command goes through. – Ƭᴇcʜιᴇ007 Apr 20 '14 at 18:21
  • Just did a simple C program (system("echo ^");) and it does NOT do this, I'm testing some other things now...??? – txtechhelp Apr 20 '14 at 18:24
  • 1
    Related question: Simple caret in batch file consumes all memory – and31415 Apr 20 '14 at 18:44
  • 1
    @and31415, thanks for that link. It does help confirm suspensions as to the 'why' it acts weird (kind of). I'm not sure if I should close this question or 'answer' it with? I do have more questions in regards to this issue, but they are more programming specific and thus I will ask on Stack Overflow. Guidance on close/answer since a relevant answer exists on SO already? – txtechhelp Apr 20 '14 at 19:08

As it turns out, this is actually a bug in how the command line (more specifically cmd.exe) parses batch files and could lead to a quick denial of service type attack; putting the following line in a batch file (with no new lines) will consume massive amounts of memory very quickly due to this bug (as an example):

^ nul<^

Long story short, when a caret is at the end of the file, the actual end of file is 'ignored' and the file handle 'reset' to 0 (essentially) so that the batch is parsed again (ad infinitum).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.