Breakpoint Failed to Bind - Visual Studio 2015

Question

I just upgraded from Visual Studio 2013 to 2015 and now I am having trouble with breakpoints.

It's a hit or a miss where break points will actually work and if I set one while debugging I get the error:

The breakpoint failed to bind.

Any help would be appreciated. I am about ready to give up on 2015 and go back.

Solution 1

I had the same problem but a different solution. Please note I updated to VS 2015 Update 1 and the problem is still there.

In previous edition of VS starting debug automatically triggered a build in debug mode. But with VS2015 it does not.

So if your last build was in release mode, and you try debugging, breakpoint won't work.

You have to manually build in debug mode first, then start debugging.

Solution 2

I had the same problem.

I solved it disabling "Optimize code" option in project properties Build tab.

Solution 3

This may seem trivial, but after a lot of headscratching with the same issues as you mention, I found out that my build was set to "release" instead of "debug" when I tried debugging.. re-building the solution for "debug" fixed it, and I could set breakpoints as normal

Solution 4

I had a similar issue with breakpoints failing to bind, as well as certain local variables not evaluating in the Locals window. What finally fixed it was enabling the "Suppress JIT optimization on module load (Managed only)" option in the Options->Debug->General tab. Once I set that it was able to bind without issue.

Solution 5

I had this problem. I ran a performance profiling session which modified the Web.config file with settings for the performance monitor:

<appSettings>
   <add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools\vsinstr.exe"/>
</appSettings>


<compilation debug="true" targetFramework="4.5" 
      assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
   ...
</compilation>


<runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
         <assemblyIdentity name="Microsoft.VisualStudio.Enterprise.AspNetHelper" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
         <codeBase version="16.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/Microsoft.VisualStudio.Enterprise.AspNetHelper.DLL"/>
      </dependentAssembly>
      <dependentAssembly>
         <assemblyIdentity name="VsWebSite.Interop" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
         <codeBase version="8.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/VsWebSite.Interop.DLL"/>
      </dependentAssembly>
   </assemblyBinding>
</runtime>

This broke my ability to stop at breakpoints. When I reverted back to the original Web.config (removed the Performance Profiler settings), the breakpoints started working again.

View more solutions

Comments

[Sealer_05]

That allowed me to set the break points but doesnt last forever. I also still have issues with debugging still skipping random lines of code still

[Sealer_05]

I gave it a shot but still wasnt hitting breakpoints in a my api controllers.

[Sealer_05]

The issue still ended up coming back on one of my projects. Anyway, Update 1 is out now so hopefully that cleans everything up visualstudio.com/en-us/news/vs2015-update1-vs.aspx

[Tolga Evcimen]

Isn't this a wierd behaviour? Can it be considered as a bug?

[hem]

Installing the Update for Microsoft Visual Studio 2015 Update 3 (KB3165756) fixed the debugging issue for me where previously I was getting "The breakpoint failed to bind ." error in the C# Views

[Repeat Spacer]

This was actually good :) I forgot the release build active and was experiencing very weird debugging session until reading this I remember to activate debug back and everything is "normal".

[Nathan]

There is a good explanation on debugging with optimized code here

[Bart Friederichs]

Isn't that the whole point of a Debug build? I would advise against a Release build with "Optimize code" turned off.

[samneric]

I had a weird experience. I had to set the build to "Release", build, then "Debug" and build again.

[Rick O'Shea]

This problem persists despite all the one-off temporary reports of success for wildly different solutions. However, this particular "fix" needs to be put along side "is your computer plugged in". It's really not a solution. Yes you do need power and yes you cannot set breakpoints in a release build -- geez.

[Rick O'Shea]

Um, no, this is not a solution. What we're getting is people randomly tweaking switching that have no bearing on the issue, that seems to disappear on its own

[Rick O'Shea]

It's almost like comedy central. I'm waiting for "I waved a rubber chicken over the machine and that worked". We've got a half dozen developers who've experienced this issue and not one of these ad hoc magical, explanation-free solutions works.

[Lee Taylor]

This was the solution for me after profiling in VS 2017. Many thanks.

[Max Favilli]

@TolgaEvcimen Given that after more than 2 years, as of VS 15.5.6, the behavior is still the same, I would say MS doesn't consider it a bug. Personally I would find it more logical to revert to the old behavior of automatically trigger a debug build. Or at least give a warning.

[BJury]

Seems like there are many causes for breakpoints failing to bind, but this is the one we saw.

[Ben Junior]

@Kenneth Møller As you mention, it may seen trivial but solved my problem too.

[Chad Hedgcock]

This was it for me. I removed this AppSetting: <add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrL‌​ocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Team Tools\Performance Tools\vsinstr.exe"/>

[Markus Schober]

Finally. This also allowed me to step through code that was previously being jumped over.

[EM0]

This solved it for me in VS 2019, thank you so much!

[FredyWenger]

I had a completely weird behavior with VS2017 and a vb.net project. Lost a full day by trying various "solutions". To enable this option was the solution!

[AaronLS]

When I looked at the Config Manager, I switched to Debug for the solution, and found some projects were incorrectly set to Release. This means selecting Debug in the drop down would cause those projects to use their Release configuration, meaning optimized.

[GrumpyRodriguez]

For anybody who encountered this problem in between two lines, this solved the problem for me in vs.net 2019. As in, I can place a breakpoint in line 100 and 102 but line 101 gives me the error in this question. Problem solved, thank you.

[mack]

Still an issue in VS 2019

[Francois Saab]

Thanks that worked for me