VS2010 (Express) debugger trapping Ctrl+C in Console app

Summary of Answers

To avoid the debugger trapping Ctrl+C first turn off the Visual Studio Hosting Process (found in project properties, Debug tab)

If you're using the Express version of Visual Studio, that's all you can do.

If you're using the Pro or better version of Visual Studio you can additionally open Debug > Exceptions..., Win32 Exceptions, and uncheck Ctrl+C.

As as alternative, you can use Ctrl+Break when debugging, unless like me Ctrl+C is hard-wired into your brain.

Original

The following has been edited. Hans seems to have retracted his answer, but his questioning has helped me to narrow down the problem statement:

Extra Clarity

• I do not want to modify the behavior of Ctrl+C.
• I'm not looking for a work around.
• I simply want the debugger to NOT break when Ctrl+C is pressed during a debugging session.

Please note that the following example is contrived. It's just to demonstrate the behavior. I changed the ReadKey line as it was distracting people.

Debug (run) the following program:

class Program
{
    static void Main()
    {
        System.Threading.Thread.Sleep(System.Threading.Timeout.Infinite);
    }
}

Press Ctrl+C. The debugger will break as if you set a breakpoint on the Sleep line.

How do you turn this off? I don't want the debugger to break at all for Ctrl+C.

This doesn't happen at home with VS2008 Pro.

I have now tried it with both VS2008 Express and VS2010 Express (the only editions I can test it with easily) and they all do it. This has led me to believe that either it's an Express behavior, or that there is a setting somewhere to toggle it on/off.

1. Is there a setting to turn this on/off in any version/edition?
2. Does this setting exist in VS2008, VS2010, or both?
3. Is the setting exposed in the Express editions?
4. Is my instance of VS2008 Pro unique? Is the setting something that was expos开发者_如何学运维ed in an old version of Visual Studio that has carried over (I have carried over VS settings through many new versions).

Perhaps this is common knowledge by now but we were having the same problem when trying to stop a topshelf application using ctrl-c while being debugged in visual studio. In the end we figured that you need to turn off capturing control-c win32 exceptions when thrown (Debug->Exceptions, or ctrl d,e open Win32 Exceptions then uncheck control-c in the thrown column) and then also go to the project (that is running the service) properties and on the debug tab check the option enable unmanaged code debugging. We are using MS Visual Studio 2010 pro version 10.0.40219.1 SP1Rel.

I found the answer, it is a debugging Exception option. I don't know how I missed it the first time, but here it is:

Debug -> Exceptions... Win32 Exceptions - Control-C

This is in VS2008 Pro.

I can also confirm that the option does NOT exist in the Express editions (the entire Win32 Exceptions node is missing).

So the only question I have left, since I don't own VS2010 Pro (yet?) is: Does the Win32 Exceptions node, and the Control-C exception exist in the VS2010 Pro edition?

There seems to be a bug in VS 2010 debugger / .NET 4 that you get a strange 'no symbols' window when Ctrl+C is pressed in a console application with only managed debugging. There is a work-around to enable mix-mode debugging. The bug says 'fixed', but if other folks are hitting this please report it on the connect bug so the fix gets into a hotfix / SP.

I saw this while debugging a service that uses TopShelf library to host a windows service which also lets you debug the service locally as a console application.

https://connect.microsoft.com/VisualStudio/feedback/details/524889/debugging-c-console-application-that-handles-console-cancelkeypress-is-broken-in-net-4-0?wa=wsignin1.0

Related Links: TopShelf, (came from MassTransit)

Update: It seems the connect bug is for VS 2010 Beta, but I'm seeing the strange 'no source available' in managed-only debugging with VS 2010 RTM with what I believe to be the latest hotfixes.

TopShelf has reported this problem:

https://github.com/Topshelf/Topshelf/issues/10

And Microsoft has acknowledged it:

https://connect.microsoft.com/VisualStudio/feedback/details/524889/debugging-c-console-application-that-handles-console-cancelkeypress-is-broken-in-net-4-0

CTRL-C is wired directly to the console window itself for the 'break' operation. Open a new console app, ping something, then immediately press CTRL-C. It aborts the ping.

You said VS Pro didn't have this behavior. I'm assuming it was just itself setting SetConsoleMode whereas VS Express doesn't. However, you can still tell the console directly to ignore CTRL-C and treat it as straight input yourself with SetConsoleMode. See this link for details:

• http://msdn.microsoft.com/en-us/library/ms682541(VS.85).aspx

Here's an example usage in C#:

• Windows Console Application Getting Stuck (Needs Key Press)

Just put the call with your chosen mode options at the beginning of your program and you should be good to go!

Hope this helps!

M