I have been using the command prompt in Windows 10 quite a lot, lately, running stuff like Node.js and Apache Tomcat servers, and I have noticed an odd problem: every now and then, the programs stop responding (in the case of these two, stop serving requests) so I focus the command-prompt window and press Ctrl+C to kill the program, intending to start it again. When I do so, however, the program immediately resumes as if it had been suspended or stuck on a debug breakpoint.

I have noticed it with several programs - not just Node and Tomcat - and want to know how/why this happens and how to stop it from happening - it is a very large problem for me - I am trying to write software using these two servers and can never tell whether my code broke or whether the command prompt just froze up.

  • Why aren't you running Tomcat as a Service? – DavidPostill Apr 18 '16 at 18:00
  • Because I only need to run it for about half an hour every few hours or so to test against an external environment - the rest of my development is served by Node.js. – Xharlie Apr 18 '16 at 18:03
  • The reason I rejected the edit to this question, is for the simple fact, programme is actually correct. It might be the british version of program but it is grammatically correct. The only real edits made to this question were to change programme to program which means it doesn't really improve the question. – Ramhound May 5 '16 at 20:12
  • any answers to this yet – Max Alexander Hanna Oct 15 '18 at 12:22

This is a pretty old question but I was having this issue and found the answer: Command prompt hangs until keypress?

  • 3
    Can you please add more information not just a link – yass Jun 15 '17 at 19:43

This is a common thing:

It also happens when using WinPE with bare-bones command prompt terminals as well as PowerShell , or modern .Net 5.0 console programs -- anything. As best I can tell it's a bug with the Windows terminals and there is no proper solution, only ways to mitigate the problem.

One answer to a different question (QuickEdit mode hang) has a comment in it that describes this phenomenon perfectly: "I've seen this for 20 years in windows. It has appeared and disappeared many times... I think its Microsoft not doing proper regression testing, because it comes and goes every few years" (gunslingor Oct 11 '19 at 16:38)

It's a plague to systems administrators:

Sometimes there's absolutely no clue when a program is hanging or just busy and not outputting text -- guess wrong and CTRL+C at the wrong time and you might end up losing hours of work (or worse--if you fail an installation of Exchange Server you'll probably end up corrupting your company's entire active directory database--good luck finding work after that).

As the QuickEdit mode hang is easily confused, it's best to identify what kind of hang you have first.

How to tell whether it's a CTRL-C hang or a QuickEdit Hang:

QuickEdit mode hangs are benevolent in that these console hangs don't actually hang the program -- the second you un-hang the console output, you're immediately greeted by a wall of new lines as the console catches up with the actual output.

To unhang it, press ESC if you're lazy, or adjust the console size if you're careful. Most keys won't do anything, RMouse will potentially paste clipboard into console if it's not actually hung (which can be catastrophic), enter will potentially execute a default input command (if not hung) or lose valuable clipboard info (as it "copies" while marking), and ESC though usually safe might give an abort command to a program. To be safe, adjust the console size.

If it's still hung, you might have a CTRL-C hang, here are mitigations to help verify:

When it's a "CTRL+C"-to-break-free hang it only resumes from exactly where it left off--if it's not hung you abort whatever you're doing, which can be catastrophic. As was mentioned above, there seems to be no fixes, just knowing your stuff and preemptively taking measures so that you can hopefully better tell if it's hung or not:

1a) "Comment" your scripts and programs by outputting to console:

For your own batch files and scripts, turn REM/etc. comments into ECHO outputs. For programs, instead of writing // Write image to share folder:, consider replacing them with Console.WriteLine($"Writing image to share, this should have no output for 10-20 minutes, the current time is {timeNow}".);

1b) Enable verbose mode:

When you're not using your own scripts and programs, see if there's a verbose option. This varies by program and context, but enabling programs' verbose output (often just by adding "-v") can be your friend when working in console directly and not working through your own automation scripts and programs.

2) Know your timings (>30s):

The first time doing something is always the hardest. But once you do it the first time, in your documentation, any time periods that are more than 30 seconds should probably be written down. If it varies based on some factor, try to list two examples:

Imaging HDD's of ~12 gigs, expect 3 minutes of no output.
Imaging HDD's of ~20 gigs, expect 8 minutes of no output.

3) Note before you act.

On a piece of paper, write down what you were running, how far along it got, how long it has been taking, how long you think it should be taking, what you expect to happen if you CTRL+C a running process and what you need to do to resume it from where it is now if that's the case. Most importantly, if you destroyed everything you were working on right now, what would be the time cost of fixing, restoring or resetting it?

Sometimes CTRL-C'ing at the wrong time can have unpredictable consequences. A program termination even if aborted can cause a computer restart if you're in the middle of a complex script. A frozen update can have devastating consequences for an OS. Are you sure you don't want to work on something else for 30 minutes to make sure it's really frozen before trying to unfreeze it? If you're not sure, don't test it yet.

4) Make sure your window is selected.

This sounds dumb, but it's the easiest mistake to make, especially when installing onto a virtual machine or a machine over RDP, even if you only have one window open, click on the terminal's top bar and try to drag it around before pressing CTRL-C (but after trying to resize the window to check for a QuickEdit mode freeze).

We need to avoid two common pitfalls:

  1. Your RDP session might be frozen -- hitting CTRL-C (interacting with the window) may help it re-establish its connection, and that CTRL-C might get erroneously passed through.
  2. More importantly, your console may not appear to un-hang when you first hit CTRL-C -- but not because it's still hung--just because it froze in the middle of a long process without output. Picture this: you think that the window is selected--you hit CTRL-C and nothing happened, you thought the window maybe wasn't selected so quickly select it and hit CTRL+C again. Then you realize that it was selected to begin with--and frozen--and though you unfroze it with the first CTRL-C, since you hit CTRL-C again after that, its process then gets aborted. Now you face-palm.

The bottom line: When you go to hit CTRL-C you want to make sure that there's no question that it registered and that you only do it once--don't let yourself have any reason to doubt whether the window was selected and responsive during the key press. If there's no response after your first CTRL-C, record the time on your piece of paper, note how long it should take to complete its current process assuming it just started from 0s based off of your timing notes from earlier repetitions of the same process, and don't try again before then (with a little time extra just in case).


Check the energy options of your computer there are not in "economic mode". If there is change it to "maximum performance".

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.