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 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. :)

Caswell

Yes, really annoying. This bug is present at least since Visual Studio 2008. The only workaround I know of consists in renaming the source file as you have found out on your own. – Shakedown

Interestingly enough, this bug is mentioned in the documentation: msdn.microsoft.com/en-us/library/h6aesyw2%28v=vs.100%29.aspx . But the workaround they suggest (entering the full path of the source file manually) doesn't seem to work, at least for me in VS 2013 U2. – Horgan

Still happening in Visual Studio 2015 – Impatiens

Still happening in Visual Studio 2022, I fix it by changing the startup project, VS is switching to the file that is in use with the currently selected startup project – Tiffany

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...

Horgan

Answer 2

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.

Beeson

Answer 3

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.)

Morningglory

I don't know why but deleting the .suo solve my problem. I just duplicated my project to another project with different name. When I debug the new project, the page keep calling the old project. Same for the breakpoint. Now it's working fine. Thanks for saving my time after wasting 3 hours – Credits

Answer 4

I had the same problem today. I was able to trace it back to the fact that I had forgotten to set the platform target to x86 while debugging. Unfortunately the others (x64 / Any CPU) can be problematic while debugging. At least VS 2008 doesn't like them. I guess this is yet another reason to stay away.

Some speculation... I think the debugger (while running a 64 bit app) somehow "steals" breakpoints away from a file in certain cases. For me it was because another assembly was loaded first which had the same file name. I was able to avoid the issue, even in 64 bit mode, if I first manually loaded the assembly with my breakpoints: Assembly.Load("MyAssemblyWithBreakpoints");

Hope this (my first stackoverflow contribution) helps.

Carn

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.

Draught

Answer 6

I just had this issue on Visual Studio 2017 (Version 15.9.7), were break points were skipped and the debugger just "jumped" over return statements etc.

After a while I noticed, that I've recently added a .runsettings file to the project - and it turned out, that in my case configuring the CodeCoverage data collector is causing this problem. As soon as I removed this section:

<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> ... </DataCollector>

from the .runsettings file, it worked like a charm again.

Pedantry

Answer 7

I just backed up and deleted the file and then added back to the project, that solved the problem. I just whish i did it before going through the beforementioned list :)

Handsaw

This is the only solution that worked for me, try this first – Contravene

Answer 8

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

Subaqueous

Answer 9

I was hitting this issue in Visual Studio 2015.

I had a sub-folder with a DLL I wanted to save as Version1. It seems even after removing the reference to that DLL, and then adding a reference to another project studio pulled in the existing reference and went to the wrong source file. I removed that DLL in the sub-folder then Studio got the correct source.

I found a helpful link on [MSDN that shows how to clear prior associated source files in studio at this link][1].

Summary:

1. In the Solution Explorer, right click on the solution name (ex: Solution ‘TestApplication’) and select Properties This will bring up the Solution Property Pages dialog
2. Under Common Properties, select Debug Source Files
3. In the Search these paths for source code files (Visual Studio .NET 2003) / Directories containing source code (Visual Studio 2005) box, add, remove and/or reorder the directories as desired
4. Click the OK button

Impatiens

Answer 10

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.

Call

Answer 11

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.

Mandrill

Answer 12

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

Kenlee

Answer 13

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).

Virgulate

Answer 14

I had a very similar problem. In my case the problem was a different target .net framework in one of the projects causing VS2017 to wrongly load a source file (with the same name) of another project, not the one being activated with

ObjectHandle handle = Activator.CreateInstance

Changing the project's target framework to be the same in all projects fixed it.

Strander

Answer 15

I had a similar issue with the breakpoint being set in another file with the same filename in a different project.

It was caused by the fact that the debugging was started for that other project, while it was not started for the project where I tried to set the breakpoint. The breakpoint creation worked correctly after doing the Debug > Start New Instance for the intended project.

Gyroplane