VS2012: Breakpoint in ntdll.dll at debugger launch with no more info

This annoying issue stems from a bug within Visual Studio:

What's happening is that we're not correctly handling multiple loader breakpoint events from different processes simultaneously. The OS triggers a loader breakpoint once the process is up and running but before any execution can take place for debuggers to instanciate breakpoints and take other action. Normally we successfully ignore these (at least in the single launch case). You can work around this by disabling the "Break all processes when one process breaks" checkbox in tools->options->debugger. Also note that this isn't a fatal error. We're just stopping at an internal breakpiont and you can just hit F5 again to keep going.

It's a race condition so won't be that easy for us to track down and multi-launch usage in VS is fairly low so I'm going to won't fix this assuming the workaround above will be good enough to get you unblocked and we'll revisit this if we see more reports from additional customers. Does that sound reasonable to you?

Thanks again for the feedback.

Marc Paine Visual Studio Debugger Engineering Manager

Source: Microsoft Connect

I followed the advice for disabling the "Break all processes when one process breaks" checkbox in the Visual Studio Debugger settings and this "removed" the issue for now.

Perhaps if we can get a few more people to report the same issue/annoyance of this bug, Microsoft will eventually fix it like they suggest.

If you run the application under a debugger, there is an automatic breakpoint as soon as the process starts. This breakpoint gives you the opportunity to set further breakpoints before the process begins executing. If you don't like it, there is usually an option in the debugger to ignore the initial default breakpoint. For example, in cdb the option is -g.