Suppose I run cmd.exe and ping localhost. After that I ping localhost again but I click into the window and the ping stops until I press enter.

What happens exactly when I click into the window? Does it suspend the process or something else? I attached a screenshot to clarify this issue.

Note: I do not actually click but drag using the mouse which creates a white box in the window as you can see on the screenshot.

Edit: further clarification: What I really wish to know is whether dragging the window halts the cmd process or not?

Edit: even more clarification: I know that I'm using Quick Edit and pressing enter copies the contents I selected. What I do not know is what happens in the background.

enter image description here


7 Answers 7


When you select some text in the cmd.exe window, the process will carry on in the background until the next time it writes to Standard Output (or STDOUT, the data stream which is shown in the cmd.exe window).

When you exit the selection mode, the process will resume as normal.

You can test this by typing ping www.google.com -t into your cmd.exe window, and selecting some area of the output. You'll see it pause, and when you deselect the output will resume.

Edit: As per Fran's comment, you can use a tool such as Wireshark to see that activity does still happen after the point when you made the selection, and then stops.

  • 3
    That alone doesn't test it. You also need to run Wireshark and see if the ICMP packets stop getting sent. If so, you are right that the process is suspended. If not, the process is not suspended, and the output simply gets buffered (until the buffers fill up, then it will either be suspended or data will be lost).
    – Fran
    Aug 9, 2012 at 17:27
  • 1
    I'm fairly sure @Fran is right - doesn't a whole bunch of output appear at once, if you waited long enough in selection mode?
    – Izkata
    Aug 9, 2012 at 18:31
  • 1
    This annoyed me a lot, but I found out that if you go to properties of the cmd windows you can deselect "Quick edit mode" and you will not enter the select mode by clicking in the window.
    – Zitrax
    Jan 30, 2015 at 9:13
  • 2
    @Zitrax yes that's how you can prevent this happening accidentally. I frequently copy things from my command window, so I don't do that. (well, actually I use Consolez which doesn't have that issue)
    – JohnL
    Jan 30, 2015 at 18:11
  • 2
    This is called "blocking"... i.e: the application calls write() but it gets stuck.
    – Attie
    Oct 8, 2018 at 6:30

Once you click into the Command Prompt window, the console host will no longer allow output to be written. The application itself keeps running, but nothing is written to the screen.

Of course, as long as there is only a single thread, this is basically the same thing as having your process frozen. As the single thread tries to write some output before doing more work.

If I run ping -t localhost and click into the command prompt window, I can then inspect the call stack of the main ping.exe thread with Process Explorer.

enter image description here

We can see that ping.exe tried to write some output. It called write() in the C runtime library. That function, at some point, calls GetConsoleMode. As it seems, that function will check if the user is currently in mark mode and block execution if needed.

Further Analysis

We can further proof this behavior by examining the behavior of ping with Wireshark

When running ping -t superuser.com we see the following output in Wireshark:
enter image description here

Now, let's mark a box in the command prompt.
enter image description here
Suddenly, no more pings are logged in Wireshark. ping is no longer sending any packets.

But we already knew that...

Right, let's see if the output is actually the issue here! Let's direct the output to the NUL device:

enter image description here

Now, there is no longer any ouput. We can now mark text in the box all day long, packets will be logged in Wireshark.

enter image description here

  • If I hadn't +1'd already for the original answer, I'd +1 now for the "Further analysis"
    – JohnL
    Aug 14, 2012 at 21:44

Your CMD windows is in quick edit mode which automatically enter the edit mode when you click on the screen. The Enter is for copy the text in the white-box and exit the edit mode.

Normally CMD only enter edit mode when you right click on the black screen and choose Mark.

To change back to normal, right click on the title bar of the windows and choose Properties, select Options tab and deselect "Quick Edit Mode" and click ok.


That is because the window has entered Mark mode. When you press enter, it copies the selected text to the clipboard. To my knowledge, there is no setting for this, so I'm not sure why it's doing that when you just click into the window. Normally you have to right click and hit "Mark". Check to make sure no keys are stuck on your keyboard.

  • And what does "Mark mode" do? Does it suspend the process?
    – Adam Arold
    Aug 9, 2012 at 16:33
  • Mark mode is used for copying text from the command window. AFAIK that is the only use, though I suppose there may be others.
    – Garrett
    Aug 9, 2012 at 16:36
  • 10
    The setting is called Quick Edit Mode. Click the icon in the top left hand corner, choose Properties and Choose Quick Edit Mode on the Options tab. From what I know, the process will continue in the background until it needs to interact with the console, at which point it will block
    – JohnL
    Aug 9, 2012 at 16:37
  • @JohnL please create an answer because your comment is what I'm looking for.
    – Adam Arold
    Aug 9, 2012 at 16:41
  • @edem Added an answer :)
    – JohnL
    Aug 9, 2012 at 16:58

When you are selecting the text to copy from the window (when in Mark mode) the system suspends the current process in that window.

Example batch file:

echo %0
goto test

when this is run, as soon as I mark the area to copy, the screen stops scrolling

  • I was about to post the exact same thing (except that my batch file was echo blah↵%0). :-)
    – Synetech
    Aug 9, 2012 at 21:04

As everyone has so nicely pointed out the progress of additional output is blocked while a mark operation is in progress. Also, either using the alternate-click of the mouse (right-click by default) or by pressing the Enter key on your keyboard you can exit Mark mode and copy the marked selection into Windows' paste buffer. There is another way out and that is to press the Esc key to abandon marking a screen area and release the block on output. This assumes that you have QuickEdit mode selected in that command window's properties. You can also get into this situation more deliberately by telling the command window that you want to select some text.


To further corroborate the statement that the process pause in "Mark mode", e.g. during a mouse click or drag inside the cmd.exe window borders, but halts any operation only after completely finishing with the instance in progress, I offer an indirect proof:

[1378:000f][2018-10-08T13:26:20] END: Verifying package "AndroidEmulator,version="
[1378:000f][2018-10-08T13:26:20] BEGIN: Verifying package "AndroidImage_ARM_API23,version="
[1378:000f][2018-10-08T13:26:20] Verifying package 'AndroidImage_ARM_API23,version='
[1378:000c][2018-10-08T13:26:26] SHA256 verification for 'AndroidImage_x86_API23,version=\x86-23_r20.zip' succeeded. Hash: X
[1378:0025][2018-10-08T14:09:03] BEGIN: Verifying "AndroidImage_ARM_API23,version=\AndroidSDKPrivateInstall.ps1"
[1378:0012][2018-10-08T14:09:03] BEGIN: Verifying "AndroidImage_ARM_API23,version=\armeabi-v7a-23_r20.zip"
[1378:0012][2018-10-08T14:09:03] Authenticode verification returned 0x800b0003 for path: AndroidImage_ARM_API23,version=\armeabi-v7a-23_r20.zip.
[1378:0012][2018-10-08T14:09:03] Retrying validation for: AndroidImage_ARM_API23,version=\armeabi-v7a-23_r20.zip
[1378:000c][2018-10-08T14:09:03] Authenticode verification returned 0x800b0003 for path: AndroidImage_x86_API23,version=\x86-23_r20.zip.

You are looking at the logging stream of a Visual Studio installation where the Visual Studio Setup Command Line Utility is verifying all the installed workloads.

At 13:26:26 I clicked the inside the Command Prompt window. The Output to screen halts till 14:09:03 when I will have hit Enter to exit "Mark mode".

Now notice that after 13:26:26, the process finishes to check x86-23_r20.zip hash, the message "succeeded. Hash: X" and restart with another file at 14:09:03, the message "BEGIN: Verifying "[..]AndroidSDKPrivateInstall.ps1"

During the pause Visual Studio Setup Command Line Utility concluded the verification of the file that was processing, and at exactly the time when the control was to be returned to the console, started a new hash check work.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .