Breakpoints cannot be hit when debugging C# in Visual Studio

When this happens, there can be a few reasons

-You attached to the wrong process.

-The build profile was changed to Release instead of Debug, thus no symbols are generated for debugging.

-You opened multiple instances of Visual Studio or programs that lock the PDB file, so when you make a new build the PDB file fails to be regenerated to match the new DLL.

-There are assemblies with classes with same name in the same namespace (for example DI may be configured to load different assemblies depending on some configuration). Visual Studio load the debug file for the wrong assembly when you are debugging some code. VS may assume that there is only one implementation of a a class in same namespace.

Steps to resolve

Make sure you attach to the correct process.

Make sure the build profile is Debug.

Clean and rebuild the solution.

If there are multiple assemblies with classes with the same name, try deleting the one that is not in use and then rebuild. Best option is to avoid classes with same name in same namespace. VS will be confused.

Last step, log out and log in again, or restart the computer to kill the processes that are locking the PDB. It could even be some Visual Studio bug.

Strategy to debug Javascript

Make sure you read the relevant API docs.

Use Chrome’s developer tools, Firebug, or IE’s, and Visual Studio debugger, they are awesome.

Use console.log and alert in code when necessary when tracing code is difficult.

Run JS scripts from JS console.

Don’t be afraid to trace through third party’s frameworks and libraries when necessary.

 

Strategies to debug irreproducible bugs, or Heisenbugs

If the code in question involves concurrency, check if there is a potential for deadlocks which occurs infrequently and hard to track.

Check for other factors: network conditions, equipment quality, environment, bugs originated from OSes or third party libraries.

Add sufficient loggings to the code in case the bug appears again by detecting the bug’s behaviour, so that in the future if it appears again you will have something to track it.

Add a notification mechanism to notify you when the bug appears again, similar to previous point.

Forget about it for a while and work on other tasks, so that you can look at it from another angle later.

Have another person with fresh eyes to look at the code and give new ideas on what might cause it.

Pass many different inputs to the code with many edge cases to see if the bug can be reproduced, might be very time consuming and not effective, but can try.

If it doesn’t appear again and you have no idea how to reproduce it, maybe it’s okay to just ignore it for the time being.