Visual Studio 2012 Express debugging explorer.exe - no breakpoint hit - by Patryk Marchwicki

Status : 

  By Design<br /><br />
		The product team believes this item works according to its intended design.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 768361 Comments
Status Resolved Workarounds
Type Bug Repros 0
Opened 10/23/2012 1:27:52 AM
Access Restriction Public


When debugging an addin with VS2010 the explorer is started in normal mode. As soon as the addin is loaded, it is switched to managed mode and VS2010 stops at the breakpoints.
With VS2012 it is different - when the addin is loaded, explorer.exe is not switched to managed mode and breakpoints are not hit.
But when I turn off VS2012 debugging, go to the folder and ensure the dll is loaded (so the explorer is switched to managed mode) and attach VS2012 to it - then the breakpoints are hit.
I use VS2010 Express and VS2012 Express on Win7 Pro x64.
I posted it on stackoverflow:

More detailed information:
Sign in to post a comment.
Posted by Patryk Marchwicki on 11/26/2012 at 3:05 PM
I'm not reopening the ticket, but I still think that it's a serious visual studio 2012 debugger bug that it doesn't "notice" managed code being loaded - "automatically detect type of code" functionality should by design automatically detect loading managed code.
Posted by Microsoft on 11/26/2012 at 11:33 AM
Sorry, this is by design for the debugger. There are many different factors that the debugger uses to determine how to attach. Even with the same version of Visual Studio, it may make a different choice depending on the Operating System or when managed code was loaded into the process.

Visual Studio Debugger Team
Posted by Patryk Marchwicki on 11/19/2012 at 9:57 AM
Is anybody reviewing this bug? It seems to be a major debugger problem, but MS has got quiet on this.
Posted by Patryk Marchwicki on 10/25/2012 at 10:48 PM
If you're still not convinced, then please explain to me why VS2012 debugger stops at the breakpoints when attached with explicitly selecting "Managed (v3.5, v3.0, v2.0)" and doesn't stop when selecting "Automatically determine the type of code to debug"?
Posted by Patryk Marchwicki on 10/25/2012 at 1:36 PM
Putting it more briefly - when selecting "Automatically determine the type of code to debug", Visual Studio 2012 Express doesn't detect explorer.exe switching from "Native code" to "Managed" when it loads managed dll, while 2010 does detect it.
Posted by Patryk Marchwicki on 10/25/2012 at 1:28 PM
explicitly selecting debug type is a workaround to the problem, not an actual solution, therefore I'm reopening the ticket.
In VS2010 Express, which btw doesn't support attaching in UI, adding the following property group do csproj:
results in debugging explorer.exe and stopping at the breakpoints, while in VS2012 Express debugging process starts but it doesn't stop at the breakpoints at all. So Visual Studio 2012 is not detecting if managed code is already running correctly - there should be no differences in stopping at the breakpoints. Maybe VS 2012 doesn't detect when explorer.exe loads managed code when it starts in native mode first?
If it is too hard to correct, then there should be added an additional PropertyGroup support - for explicitly selecting debugging the mode (same as when attaching in UI) - for example <StartMode>Managed</StartMode>.
Posted by Microsoft on 10/25/2012 at 11:44 AM

Visual Studio does not actually determine how explorer.exe is running. Instead, Visual Studio is simply detecting whether managed code is already running in the process in order to make a debug engine choice for you. If you always want to debug managed code, you can click on the select button on the "Attach to Process" dialog and manually choose to debug using managed code.

Visual Studio Debugger Team
Posted by Microsoft on 10/24/2012 at 2:09 AM
Thanks for your feedback.

We are rerouting this issue to the appropriate group within the Microsoft Visual Studio Connect Support Team for triage and resolution. These specialized experts will follow-up with your issue.
Posted by Microsoft on 10/23/2012 at 1:50 AM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(