Visual Studio breakpoints break in the wrong source file (or multiple files simultaneously) if multiple files have the same name

Question

In a team project I\'m working on, setting a breakpoint in a file (say IdeasController.cs) will lead to erratic debugger behaviour if there\'s another file with

Answer 1

If no better alternatives exist, you could put the breakpoint in code:

System.Diagnostics.Debugger.Break();

Just don't forget to remove it afterwards...

Answer 2

I was having the same issue. In my case both the projects had same port numbers. I was able to resolve it by changing the port number of the project whose file's breakpoints were not hitting.

My guess is that IIS Express was caching the pdb file from the second project since both files had the same name, and the projects had the same port number.

Answer 3

It happened to me (in VS 2008) to have two child breakpoint with the same memory address and the same associated file. Those breakpoints were spawned at a certain time during the running of the process.

I noticed that I had duplicated .dll files in my project folders, and resolved removing the duplicated .dll, while keeping only one .dll per name in the debugging folder structure. (As example in my case I had /bin/Example.dll and /bin/Plug-in/Example.dll both present under my debug folder structure).

Answer 4

I'm so glad I found this post, thought I was the only one and was going insane! I'm having the same problem in VS2012 with VB.Net and have tried everything the OP mentioned.

Unique naming of the files seems to be the only 100% fix that I've found. Disabling all breakpoints until the application has loaded and then re-enabling the breakpoints you need works most of the time. Breakpoints in Lambda functions can still give you issues.

Answer 5

Although renaming one of the files will work, I found that the simplest solution is to temporarily disable automatic loading of symbols for the "other" assembly.

1. Start the debugger and continue until you hit the erroneous breakpoint.
2. Find where the debugger actually set the breakpoint using the Call Stack window:
   1. Right-click on the row with the yellow arrow and enable Show Module Names. (The row should also have the red breakpoint symbol on it.)
   2. The assembly name is now visible on that row.
3. Find that assembly in the Modules window (Debug > Windows > Modules).
4. Right-click on the assembly and disable Always Load Automatically.
5. Stop the debugger.
6. Start debugging again.

By doing this, you're preventing the Visual Studio debugger from mapping the breakpoint to the wrong assembly. It will then load the symbols from the other [presumably] correct assembly first, therefore mapping the breakpoint to the correct assembly.

Why does this happen?

This seems to occur when two different symbol files (PDB files) — for two different assemblies — both reference a source file with the same name. Although the source files are completely different, the Visual Studio debuggger seems to get confused.

For example, imagine there are two different files both with the name IdeasController.cs. The first one compiles into assembly Api.dll, and the second one compiles into assembly Web.dll.

When the debugger loads symbols, it will either load Api.pdb or Web.pdb first. Let's say it loads Api.pdb first. Then even if you set a breakpoint in Web\IdeasController.cs, it will find a match for IdeasController.cs in Api.pdb. It then maps code from Web\IdeasController.cs to Api.dll. This won't map correctly, of course, and so you see all sorts of odd issues while debugging.

Answer 6

What worked for me (VS2017) was disabling this option in Tools --> Options... --> Debugging --> General: "Require sources files to exactly match the original version", which is enabled by default but I had it turned on.

That was not enough though, I also had to manually remove obj and bin folders for all projects in solution.