How do I make Visual Studio pause after executing a console application in debug mode?

Question

I have a collection of Boost unit tests I want to run as a console application.

When I'm working on the project and I run the tests I would like to be able to debug the tests, and I would like to have the console stay open after the tests run.

I see that if I run in release mode the console window stays up after the program exits, but in debug mode this is not the case.

I do not want to add 'system("pause");' or any other hacks like reading a character to my program. I just want to make Visual Studio pause after running the tests with debugging like it would if I were running in release mode. I would also like it if the output of tests were captured in one of Visual Studio's output windows, but that also seems to be harder than it should be.

How can I do this?

possible duplicate of [Preventing console window from closing on Visual Studio C/C++ Console application](http://stackoverflow.com/questions/1775865/preventing-console-window-from-closing-on-visual-studio-c-c-console-applicatio) — user, Mar 09 '14 at 22:43

score 128 · Answer 1 · edited Dec 10 '17 at 00:36

128

Try to run the application with the Ctrl + F5 combination.

edited Dec 10 '17 at 00:36

Peter Mortensen

30,738
21
105
131

answered Dec 14 '08 at 10:07

Cichy

1,313
2
8
2

24

Isn't Ctrl+F5 running without debugging? – huff Dec 08 '10 at 02:19
9

this OP wants to run in Debug mode - this runs in Release Mode. – Lloyd Jan 27 '12 at 12:27
8

@Lloyd: this isn't accurate - it runs the current configuration (which may or not be Debug) _outside_ the debugger. There is no such thing as 'Release Mode' in VisualStudio – the_mandrill Aug 05 '13 at 13:52
This is still a useful answer if you're trying to figure why an application is crashing (uncaught exception) and you'd like to review the error. There are better ways but this is quick and easy. +1 – Yuck Mar 04 '14 at 14:40
If you run Windows in a VM on a Mac, you need to disable the default Ctrl+F5 binding (Mac Settings > Keyboard > Shortcuts > Keyboard) – Neal Ehardt Jan 26 '15 at 22:17

score 78 · Answer 2 · answered Feb 03 '12 at 14:35

http://connect.microsoft.com/VisualStudio/feedback/details/540969/missing-press-any-key-to-continue-when-lauching-with-ctrl-f5

In the older versions it would default to the console subsystem even if you selected "empty project", but not in 2010, so you have to set it manually. To do this select the project in the solution explorer on the right or left (probably is already selected so you don't have to worry about this). Then select "project" from the menu bar drop down menus, then select "project_name properties" > "configuration properties" > "linker" > "system" and set the first property, the drop down "subsystem" property to "console (/SUBSYSTEM:CONSOLE)". The console window should now stay open after execution as usual.

*THIS* is the correct answer, yet it got no points, and an answer to another question got all the points, while the accepted answer is an over-complication that only works in one scenario (using boost tests). It pays to scroll down sometimes... — Amir Abiri, May 13 '12 at 19:02
Looks like this is a C++-only answer. C# projects have the same issue, but a different set of properties that doesn't include these options. — Marc Stober, Feb 12 '13 at 14:04

score 19 · Accepted Answer · edited Dec 09 '17 at 22:51

19

Boost test offers the following usage recommendations for Visual Studio that would enable you to run the unit tests automatically at the end of compilation and capture the output into the build window.

The nice side effect of this trick is it enable you to treat test failures as compilation errors. "...you could jump through these errors using usual keyboard shortcuts/mouse clicks you use for compilation error analysis..."

edited Dec 09 '17 at 22:51

Peter Mortensen

30,738
21
105
131

answered Oct 11 '08 at 06:56

Raz

1,932
2
18
23

Update: This still holds for VS2012 and Boost 1.52 - not the most current version, but I guess that 1.54 will do, too. – TobiMcNamobi Aug 02 '13 at 07:52

score 12 · Answer 4 · answered Oct 11 '08 at 04:20

12

Set a breakpoint on the last line of code.

answered Oct 11 '08 at 04:20

Kevin Timmerman

155
2

Nice, is there a hot key to continue after hitting the break point? – Hellonearthis Jan 01 '13 at 19:39
Sure, hit F5 to continue after the breakpoint! (also very handy: F10, F11, Shift+F11) – Ela782 Apr 28 '13 at 21:04
And you can also press F9 to set the breakpoint on the last line of code. Also note that the console window might launch minimized, so you need to select it after debugging (F5). – Jens Bodal Sep 29 '14 at 22:24
What if an exception is thrown earlier or there are multiple return paths from that code and it might not reach that breakpoint? – yerlilbilgin Dec 13 '18 at 09:53

score 8 · Answer 5 · edited Dec 10 '17 at 00:35

I just copied from http://social.msdn.microsoft.com/forums/en-US/Vsexpressvc/thread/1555ce45-8313-4669-a31e-b95b5d28c787/?prof=required:

The following works for me :-)

/////////////////////////////////////////////////////////////////////////////////////

Here is another reason the console may disappear. And the solution:

With the new Visual Studio 2010 you might see this behavior even when you use Ctrl + F5 aka "start without debugging". This is most likely because you created an "empty project" instead of a "Win32 console application". If you create the project as a "Win32 console application" you can disregard this as it does not apply.

In the older versions it would default to the console subsystem even if you selected "empty project", but not in Visual Studio 2010, so you have to set it manually. To do this select the project in the solution explorer on the right or left (probably is already selected so you don't have to worry about this).

Then select "project" from the menu bar drop down menus, then select "project_name properties" → "configuration properties" → "linker" → "system" and set the first property, the drop down "subsystem" property to "console (/SUBSYSTEM:CONSOLE)". The console window should now stay open after execution as usual.

/////////////////////////////////////////////////////////////////////////////////////

the setting "not set" for me. changing it to "console (/SUBSYSTEM:CONSOLE)" worked! — Mike Ohlsen, Jun 15 '11 at 15:31

score 6 · Answer 6 · edited Dec 10 '17 at 00:31

6

If it is a console application, use Ctrl + F5.

edited Dec 10 '17 at 00:31

Peter Mortensen

30,738
21
105
131

answered Nov 14 '10 at 01:56

delhister

69
1
1

Die in Sente · Answer 7 · 2017-12-11T10:26:10.490

You say you don't want to use the system("pause") hack. Why not?

If it's because you don't want the program to prompt when it's not being debugged, there's a way around that. This works for me:

void pause () {
    system ("pause");
}

int main (int argc, char ** argv) {
    // If "launched", then don't let the console close at the end until
    // the user has seen the report.
    // (See the MSDN ConGUI sample code)
    //
    do {
        HANDLE hConsoleOutput = ::GetStdHandle (STD_OUTPUT_HANDLE);
        if (INVALID_HANDLE_VALUE == hConsoleOutput)
            break;
        CONSOLE_SCREEN_BUFFER_INFO csbi;
        if (0 == ::GetConsoleScreenBufferInfo (hConsoleOutput, &csbi))
            break;
        if (0 != csbi.dwCursorPosition.X)
            break;
        if (0 != csbi.dwCursorPosition.Y)
            break;
        if (csbi.dwSize.X <= 0)
            break;
        if (csbi.dwSize.Y <= 0)
            break;
        atexit (pause);
    } while (0);

I just paste this code into each new console application I'm writing. If the program is being run from a command window, the cursor position won't be <0,0>, and it won't call atexit(). If it has been launched from you debugger (any debugger) the console cursor position will be <0,0> and the atexit() call will be executed.

I got the idea from a sample program that used to be in the MSDN library, but I think it's been deleted.

NOTE: The Microsoft Visual Studio implementation of the system() routine requires the COMSPEC environment variable to identify the command line interpreter. If this environment variable gets messed up -- for example, if you've got a problem in the Visual Studio project's debugging properties so that the environment variables aren't properly passed down when the program is launched -- then it will just fail silently.

score 3 · Answer 8 · edited Dec 10 '17 at 00:22

In Boost.Test there is the --auto_start_dbg parameter for breaking into the debugger when a test fails (on an exception or on an assertion failure). For some reason it doesn't work for me.

See http://www.boost.org/doc/libs/1_40_0/libs/test/doc/html/utf/usage-recommendations/dot-net-specific.html

For this reason I have created my custom test_observer that will break into the debugger when there is an assertion failure or an exception. This is enabled on debug builds when we are running under a debugger.

In one of the source files of my unit test EXE file I have added this code:

#ifdef _DEBUG

#include <boost/test/framework.hpp>
#include <boost/test/test_observer.hpp>

struct BoostUnitTestCrtBreakpointInDebug: boost::unit_test::test_observer
{
    BoostUnitTestCrtBreakpointInDebug()
    {
        boost::unit_test::framework::register_observer(*this);
    }

    virtual ~BoostUnitTestCrtBreakpointInDebug()
    {
        boost::unit_test::framework::deregister_observer(*this);
    }

    virtual void assertion_result( bool passed /* passed */ )
    {
        if (!passed)
            BreakIfInDebugger();
    }

    virtual void exception_caught( boost::execution_exception const& )
    {
        BreakIfInDebugger();
    }

    void BreakIfInDebugger()
    {
        if (IsDebuggerPresent())
        {
            /**
             * Hello, I know you are here staring at the debugger :)
             *
             * If you got here then there is an exception in your unit
             * test code. Walk the call stack to find the actual cause.
             */
            _CrtDbgBreak();
        }
    }
};

BOOST_GLOBAL_FIXTURE(BoostUnitTestCrtBreakpointInDebug);

#endif

score 1 · Answer 9 · answered Aug 05 '13 at 12:54

1

Adding the following line will do a simple MS-DOS pause displaying no message.

system("pause >nul | set /p \"=\"");

And there is no need to Ctrl+F5 (which will make your application run in Release Mode)

answered Aug 05 '13 at 12:54

zurfyx

31,043
20
111
145

this is what i do in a pinch.. but I use one line. `system("pause");` and thats it! – Señor CMasMas Oct 21 '22 at 23:46

score 1 · Answer 10 · answered Oct 11 '08 at 01:04

1

It would actually be more effort, but you could just build in VS.Net, run it from the regular command line (cmd.exe), and then attach to the process after it starts running. This is probably not the solution you are looking for however.

answered Oct 11 '08 at 01:04

Kibbee

65,369
27
142
182

The reason I'm not looking for this solution is because it's a bit heavy handed. I want my tests to run with debugging assertions enabled, so I do want to run in debug mode but I also want to see the test suite output. – Jason Dagit Oct 11 '08 at 01:06

score 1 · Answer 11 · edited Dec 10 '17 at 00:33

1

I would use a "wait"-command for a specific time (milliseconds) of your own choice. The application executes until the line you want to inspect and then continues after the time expired.

Include the <time.h> header:

clock_t wait;

wait = clock();
while (clock() <= (wait + 5000)) // Wait for 5 seconds and then continue
    ;
wait = 0;

edited Dec 10 '17 at 00:33

Peter Mortensen

30,738
21
105
131

answered Feb 15 '11 at 23:35

Mattias

11
1

score 1 · Answer 12 · answered Oct 26 '11 at 03:28

Or you could use boost_test "Test Log Output."

http://www.boost.org/doc/libs/1_47_0/libs/test/doc/html/utf/user-guide/test-output/test-log.html

Then it won't matter whether the console window shows up at all AND your build logging can preserve the unit testing output as an artifact for examination on failed builds...

score 0 · Answer 13 · edited Dec 10 '17 at 00:04

0

Just use a logging library, like log4net, and have it log to a file appender.

edited Dec 10 '17 at 00:04

Peter Mortensen

30,738
21
105
131

answered Oct 11 '08 at 01:16

Bob King

25,372
6
54
66

Well, this is C++ but I get your point. I'm using the BOOST unit testing stuff. I could log things in the test that way, but I have no idea how to make the boost test framework log to somewhere special. – Jason Dagit Oct 11 '08 at 01:20

score 0 · Answer 14 · answered Oct 11 '08 at 01:58

0

You could also setup your executable as an external tool, and mark the tool for Use output window. That way the output of the tool will be visible within Visual Studio itself, not a separate window.

answered Oct 11 '08 at 01:58

Andrew

11,894
12
69
85

score 0 · Answer 15 · answered Mar 13 '10 at 23:21

I start the app with F11 and get a breakpoint somewhere in unit_test_main.ipp (can be assembly code). I use shift-f11 (Step out) to run the unit test and get the next assembly instruction in the CRT (normally in mainCRTStartup()). I use F9 to set a breakpoint at that instruction.

On the next invocation, I can start the app with F5 and the app will break after running the tests, therefore giving me a chance to peek at the console window

score 0 · Answer 16 · edited Dec 10 '17 at 00:30

0

Do a readline at the end (it's the "forma cochina", like we say in Colombia, but it works):

static void Main(string[] args)
{
    .
    .
    .
    String temp = Console.ReadLine();
}

edited Dec 10 '17 at 00:30

Peter Mortensen

30,738
21
105
131

answered Jun 05 '10 at 17:40

Daniel Gomez Rico

15,026
20
92
162

2

question specifically says "I do not want to add 'system("pause");' or any other hacks like reading a character to my program. " – csauve Dec 22 '10 at 23:05
2

This isn't a C++ solution either...? – WiredPrairie Dec 22 '13 at 22:00
Although the question says no code the said setting in other answers is either no available or not working due to bugs in Visual Studio. So this is really a good workaround. – er.bhargav.vyas Jul 22 '23 at 11:38

score 0 · Answer 17 · answered Jan 12 '20 at 23:40

Prompt for user input.

https://www.youtube.com/watch?v=NIGhjrWLWBo

shows how to do this for C++. For Node.js, this is taken right from the docs (and it works):

'use strict';

console.log('Hello world');

const readline = require('readline');
const rl = readline.createInterface({
    input: process.stdin,
    output: process.stdout
});

rl.question('Press enter to continue...', (answer) => {
    rl.close(); /* discard the answer */
});

How do I make Visual Studio pause after executing a console application in debug mode?

17 Answers17

Linked