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 se

Answer 1

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.

Answer 2

I had the same issue yesterday. I used the "Clean Solution" feature and it helped.

Answer 3

I just ran into a similar problem and none of the answers here hit on the issue I was facing. Unlike in the question, though, I never receive any message saying there was a failure to bind. The breakpoint just never hits. Hopefully this is helpful to someone in the future banging their head on the wall with WCF.

TL/DR:
In the SOAP message there was a record with bad data caused the breakpoint not to get hit.

Full Story:

I have a WCF service based on WSDL from another team. Not my definition, no control over it... I receive messages from this other team through this service. In my case I receive messages, can log the message to the message log table in the database (which happens prior to my service method getting called), the service method is seemingly called (maybe it isn't), and the server responds with a 202 Accepted. Communication is working, except no data gets saved to the database during the method call.

Since the service returns a success response I ruled out http and transport related issues.

So I fired up VS2015 to debug the service. The message in question is large but well within the limits of what I would expect. I put a breakpoint on the first line of the service method and sent the large message through, but the breakpoint never hit. I tried a smaller message that I knew worked on the very same run instance and the breakpoint was hit just fine. So everything in the configuration seemed fine. I thought maybe there was something in the message size.

I tried everything I could find - making sure I was in a debug config, clean and rebuild, manually attaching the debugger to the w3wp process (which VS already was), using Debugger.Break() instead of a breakpoint, setting multiple startup projects, unloading my test project so that the service project was the only one, updating .NET, restarting VS2015, rebooting, switching from Local IIS to IIS Express and back, recreating the service with the guaranteed latest WSDL. Nothing mattered. The breakpoint was never hit.

I ended up having to weed out records in the large message one by one until I found one single record that had bad data. In my case it was one record that had no value for 2 DateTime fields. When I created a message that had just this one record in it and sent it, the breakpoint did not get hit. When I provided values for those 2 DateTime fields and sent the same (fixed) message in the breakpoint fired as expected.

I had every single CLR exception enabled, nothing fired other than missing .pbd files, which I didn't care about. WCF happily sent the request with a bad record through. I'm not saying that WCF shouldn't have sent it through based on the contracts, just that the bad record caused the breakpoint not to be hit.

Answer 4

I looked over the previous answers and @Will's answear fixed the main issue i was having, the other being able to edit and continue but taking an closer look at the AssemblyInfo.cs file i found out some debugging features where disabled.

Then i ended up removing old debug attributes and adding the following that i took from another project

#if DEBUG
[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.DisableOptimizations | System.Diagnostics.DebuggableAttribute.DebuggingModes.EnableEditAndContinue | System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | System.Diagnostics.DebuggableAttribute.DebuggingModes.Default)]
#endif

Yet i feel like this is not the best way of doing it.

Answer 5

STEP 1, Rule out the obvious:

• Compile in Debug mode.
• Try to Clean Solution before setting the breakpoint.
• Go to the Debug folder, and delete [Your application].pdb file.
• Then do a Build or Rebuild your application.
• Go to the Debug folder and confirm you have a brand new [Your application].pdb file.
• Then try to set your break point.

STEP 2 For C++ projects:

Check the following project properties:

• C++/General/Debug Information Format: Program Database.
• C++/Optimization: Disabled.
• C++/Code generation/Runtime library: Multi-threaded Debug.
• Linker/Debugging/Generate Debug Info: Yes.
• Linker/Debugging/Generate program database: $(TargetDir)$(TargetName).pdb.
• Linker/Manifest File/Generate Manifest: No.
• Linker/Manifest File/Allow Isolation: No.
• Linker/Embedded IDL/Ignore embedded IDL: Yes.

• Do Step 1 Again

  You can try adding __debugbreak(). This statement needs to go in your source file where you want to break.

STEP 2 For C# projects:

• In the projects properties Build/General/Optimize code should be disabled.
• In the IDE settings Debug/Options and Settings/Debugging/General Suppress JIT optimization on module load (Managed only): Enabled
• Do Step 1 Again

Try opening your solution on another machines. If you can bind a breakpoint on a different machine this can mean that there is an issue with either your VS or your OS.

STEP 3, Make sure your VS is up-to-date:

There have been reports of issues like this in the VS2013 RTM as well as VS2015 Update 1 and Update2.

In VS go to Tools/Extensions & Updates/Updates/Product Updates and see what version you are running. If an update is needed it will appear there.

STEP 4, Make sure your OS is up-to-date:

Lastly, if your running a Win 10 OS, there was a reported bug regarding this issue which existed in build 14251. This was resolved in build 14257 (and above).

Answer 6

Change Release mode to Debug, In my case, this fixed my problem.