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

Question

Occasionally when I launch/debug my application in Debug mode, using VS2012, I get a dialog:

<blahblah.exe> has triggered a breakpoint.

It contains no other information, so I hit break to see what's going on. Oh, but then I get "wntdll.pdb not loaded", and no other information on the problem. The call stack points at ntdll.dll, and it appears my application hasn't even begun execution yet at this point.

Choosing continue at this point will let the application/debugger continue as usual.

This occurs very frequently (about 7 launches out of 10). I'm running Windows 8 (64-bit), and Visual Studio 2012 with update 1.

Previously I had Windows 7 (64-bit) and VS2010, and never got this problem. This particular project has been upgraded from the version it was created in (2010), so maybe that's part of the issue.

Anyone run into this problem before? I've no idea where to start looking for a cause. Though I'm running a 64-bit Windows, I should mention that I'm building a 32-bit application.

Update: After enabling Microsoft Symbol Servers, here's what the call stack looks like:

>   ntdll.dll!_LdrpDoDebuggerBreak@0()  Unknown
    ntdll.dll!_LdrpInitializeProcess@8()    Unknown
    ntdll.dll!__LdrpInitialize@8()  Unknown
    ntdll.dll!_LdrpInitialize@8()   Unknown
    ntdll.dll!_LdrInitializeThunk@8()   Unknown

I should also add, just in case, that I definitely have no breakpoints set manually anywhere in my code.

Answer 1

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.