在我正在处理的团队项目中，如果解决方案中存在另一个具有相同名称的文件，则在文件中设置断点（例如IdeasController.cs）将导致调试器行为不稳定。我在几个开发人员的工作站上重现了这个问题。
我在Web API中的IdeasController.cs中设置了一个断点：
另一个名为IdeasController.cs的文件存在于我们单独的MVC 4 Web项目中。在下面的屏幕截图中，调试器显示了Api->IdeasController源代码，但行突出显示与Web->IdeasController的代码结构相匹配。断点是重复的，其中一个位于注释块的中间。
Breakpoint窗口同时显示两个文件中的断点：
在某些工作站上，调试器会逐步执行正确的行（无论行突出显示）;在其他人身上，它愉快地介绍了不相关的行（包括评论和空白）。我猜这取决于它选择显示哪个源文件。
我拖网上网了。当调试文件（*.pdb），源文件和编译代码之间不匹配时，似乎会出现这种问题。有很多可能的原因：重复的文件名（可能会混淆debugger[5]），过时的项目构建文件，无效的解决方案缓存或不正确的构建配置。
这些是我发现并尝试过的解决方案：
Debug> Windows> Modules。两个程序集都列出，未进行优化，符号状态为“已加载符号”。）*.suo）.[1]
删除了每个项目的构建输出（bin和obj文件夹）。 （供将来参考：在Windows资源管理器中打开解决方案文件夹，然后在搜索框中输入：“type:folder AND (name:=bin OR name:=obj)”。
删除了程序集缓存文件夹（C:\Documents and Settings\<user>\Local Settings\Application Data\dl3）.[2][3]这些都没有任何影响。我可以重命名其中一个文件（不重命名类）来暂时解决问题，但这远非理想。
我最新的Google搜索的第14页。建议将不胜感激。 :)
我很高兴我找到这篇文章，以为我是唯一一个疯了！我在VS2012中使用VB.Net遇到了同样的问题，并尝试了OP提到的所有内容。
文件的唯一命名似乎是我发现的唯一100％修复。在应用程序加载之前禁用所有断点，然后重新启用所需的断点，大部分时间都可以使用。 Lambda函数中的断点仍然可以为您提供问题。
对我有用的（VS2017）是在Tools --> Options... --> Debugging --> General中禁用此选项：“要求源文件与原始版本完全匹配”，默认情况下启用但我已将其打开。
这还不够，我还必须为解决方案中的所有项目手动删除obj和bin文件夹。
删除断点错误发生的项目的所有.pdb文件。这将解决问题。
我（在VS 2008中）发生了两个具有相同内存地址和相同关联文件的子断点。这些断点是在流程运行期间的某个时间产生的。
我注意到我在项目文件夹中有重复的.dll文件，并解决了删除重复的.dll，同时在调试文件夹结构中每个名称只保留一个.dll。 （例如在我的情况下，我有/bin/Example.dll和/bin/Plug-in/Example.dll都存在于我的调试文件夹结构下）。
我有一个非常相似的问题。在我的情况下，问题是其中一个项目中的一个不同的目标.net框架导致VS2017错误地加载另一个项目的源文件（具有相同名称），而不是被激活的项目
ObjectHandle handle = Activator.CreateInstance
将项目的目标框架更改为在所有修复它的项目中相同。
如果没有更好的替代方法，可以将断点放在代码中：
System.Diagnostics.Debugger.Break();
只是不要忘记之后删除它...
我刚才遇到了同样的问题。为我解决的是删除属于包含受影响的项目/源文件的解决方案的.suo文件。
我也删除了我的本地符号缓存，但我不认为它与它有任何关系。
（我的解决方案包含多个项目，一个项目中的一个文件（DataAdapter.cs）受此影响（VisualStudio将我的断点放在属于System.Data.DataAdapter的pdb中）。我直接打开了.csproj文件并且能够正确设置断点。）
我今天遇到了同样的问题。我能够追溯到我忘记在调试时将平台目标设置为x86这一事实。不幸的是，其他（x64 /任何CPU）在调试时可能会出现问题。至少VS 2008不喜欢他们。我想这是远离的另一个原因。
一些推测......我认为调试器（在运行64位应用程序时）在某些情况下以某种方式“窃取”断点远离文件。对我来说，这是因为首先加载了另一个具有相同文件名的程序集。我能够避免这个问题，即使在64位模式下，如果我首先使用我的断点手动加载程序集：Assembly.Load（“MyAssemblyWithBreakpoints”）;
希望这（我的第一个stackoverflow贡献）有所帮助。
虽然重命名其中一个文件可行，但我发现最简单的解决方案是暂时禁用“其他”程序集的符号自动加载。
通过执行此操作，您将阻止Visual Studio调试器将断点映射到错误的程序集。然后它将首先从其他[推测]正确的装配加载符号，因此将断点映射到正确的装配。
当两个不同的符号文件（PDB文件） - 两个不同的程序集 - 都引用具有相同名称的源文件时，似乎会发生这种情况。虽然源文件完全不同，但Visual Studio调试器似乎感到困惑。
例如，假设有两个名为IdeasController.cs的不同文件。第一个编译成汇编Api.dll，第二个编译成汇编Web.dll。
当调试器加载符号时，它将首先加载Api.pdb或Web.pdb。让我们说它首先加载Api.pdb。那么即使你在Web\IdeasController.cs中设置一个断点，它也会在IdeasController.cs中找到Api.pdb的匹配。然后它将代码从Web\IdeasController.cs映射到Api.dll。当然，这不会正确映射，因此您在调试时会看到各种奇怪的问题。
我刚刚在Visual Studio 2017（版本15.9.7）上遇到此问题，跳过了断点，调试器只是“跳过”了返回语句等。
过了一会儿，我注意到，我最近在项目中添加了一个.runsettings文件 - 事实证明，在我的情况下，配置CodeCoverage数据收集器会导致此问题。我删除此部分后立即：
<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>
从.runsettings文件中，它再次像魅力一样。
我刚刚备份并删除了文件，然后又添加回项目，解决了问题。我只是在完成前面提到的清单之前做过这件事:)
我在Visual Studio 2015中遇到了这个问题。
我有一个子文件夹，其中包含我想要保存为Version1的DLL。甚至在删除对该DLL的引用之后，然后在现有引用中添加对另一个项目工作室的引用并转到错误的源文件。我在子文件夹中删除了该DLL，然后Studio获得了正确的源代码。
我在[MSDN上找到了一个有用的链接，显示了如何在此链接中清除工作室中先前关联的源文件] [1]。
摘要：
您也可以尝试清理和重建（而不是构建）所有项目。