Visual Studio breakpoints break in the wrong sourc

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 the same name in the solution. I've reproduced the problem on several developers' workstations.

Example

I set a breakpoint in IdeasController.cs in our Web API:

Another file called IdeasController.cs exists in our separate MVC 4 web project. In the screenshot below, the debugger shows the Api->IdeasController source code, but the line highlight matches the code structure of Web->IdeasController. The breakpoint is duplicated, with one of them in the middle of a comment block.

The Breakpoint window shows the breakpoint in both files simultaneously:

On some workstations the debugger steps through the correct lines (regardless of the line highlight); on others it cheerfully steps through irrelevant lines (including comments and whitespace). I'm guessing this depends on which source file it chooses to display.

What I've tried

I've trawled the Internet. This kind of problem seems to occur when there's a mismatch between the debug file (*.pdb), the source file, and the compiled code. There are a lot of possible causes: duplicate file names (which can confuse the debugger^[5]), outdated project build files, invalid solution cache, or incorrect build configuration.

These are the solutions I've found and tried:

• Checked my build configuration.
  1. Made sure the project isn't built in release mode.
  2. Made sure we don't have code optimization enabled.
  3. Made sure the project's debug module was loaded correctly. (Started debugging the project and checked Debug > Windows > Modules. Both assemblies are listed, not optimized, and have a symbol status of "Symbols loaded".)
• Reset the debugging metadata & Visual Studio cache.
  1. Closed Visual Studio and deleted the solution cache file (*.suo).^[1]
  2. Deleted each project's build output (the bin and obj folders). (For future reference: open the solution folder in Windows Explorer and type this in the search box: "type:folder AND (name:=bin OR name:=obj)".
  3. Deleted the assembly cache folder (C:\Documents and Settings\<user>\Local Settings\Application Data\dl3).^[2][3]

None of these had any effect. I can rename one of the files (without renaming the class) to temporarily work around the problem, but that's far from ideal.

Where I am now

Page 14 of my latest Google search. Suggestions would be much appreciated. :)

Answer 1

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 2

Delete all the .pdb files of the project where the break point is hitting wrongly. This will solve the issue.

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 just had the exact same problem. What solved it for me was deleting the .suo files belonging to the solution that contained the affected project/source file.

I also deleted my local symbolcache but I don't think that had anything to do with it.

(My solution contains multiple projects, one file (DataAdapter.cs) in one project was affected by this (VisualStudio put my breakpoints in the pdb belonging to System.Data.DataAdapter). I opened the .csproj file directly and was able to correctly set the breakpoint.)

Answer 5

You may also try to Clean and Rebuild (not Build) all projects.