我已经使用调试信息（编译器选项/ Zi和链接器选项/ DEBUG）构建了一个特定的dll。通过主程序中的中断语句，我启动了Visual Studio进行调试。在Debug-＆gt; Windows菜单中显示的模块列表中，我可以看到已经为感兴趣的dll加载了符号。但是当我从该dll打开C ++文件并尝试设置断点时，它说调试符号不适用于该文档。毫无疑问，这个C ++文件被编译成该dll，并且它与用于构建dll的源相同（我只做了它）。为什么会这样？在我开枪之前请帮忙。
答案 0 :(得分：3)
我没有明确的答案，只有一些建议。
有时mdm.exe（计算机调试管理器）停止正常工作。终止进程并重新启动Visual Studio会有所帮助。如果重新启动之间问题仍然存在，那可能不是原因。
未来的源文件时间（上次修改）会导致各种奇怪的问题。要检查文件时间，您可以搜索任何内容（Windows XP）或“*”（Windows 7）。这将列出所选文件夹中的所有文件。然后按日期对结果进行排序以查看最大/最小文件时间。我有不知道不正确的文件时间来自哪里 - 我只是知道它不时发生。可能是Visual Studio本身，可能是我正在使用的其他工具。
您可以尝试启动从Visual Studio使用DLL的应用程序，并且您的DLL项目已经打开。为此，打开“配置属性”，选择“调试”页面，然后输入应该启动的.exe（如果需要，则输入+参数）。然后像启动.exe项目一样启动调试会话。
解决Visual Studio的许多问题是手动“清理”项目，并进行完全重新编译。删除在构建过程中生成的所有文件或存储解决方案或项目“选项”的文件。即所有.suo .ncb .user文件以及“intermediate”和“output”文件夹中的所有内容。如果您正在使用源代码管理，只需将源代码管理系统中的整个项目检索到一个干净的目录中，然后从头开始重新构建。 （从源代码控制中获取所有“新鲜”也可以解决任何潜在的文件时间问题 - 至少对于不保留文件时间的源代码管理系统而言）
另一个可能的原因是VS加载了错误的.pdb文件。可以在为VS配置的符号服务器/符号目录（或通过_NT_SYMBOL_PATH变量的系统范围）或VS符号缓存目录中找到具有匹配名称的.pdb文件。具有匹配名称的.pdb文件如何出现在这样的位置是一个不同的故事，但可以轻松检查是否加载了错误的.pdb文件：删除构建生成的.pdb文件，并启动调试会话。如果VS跟踪有问题的.exe / .dll的“符号加载”，则必须在其他位置找到.pdb文件。
有时VS似乎以某种方式扰乱了断点位置。我不确切知道何时或如何发生，但其中一个症状是，如果删除一些断点，它们会在启动下一个调试会话时神奇地重新出现。我发现设置一个新的断点，然后通过Debug / Delete All Breakpoints删除所有断点，并重新设置所需的断点有帮助。
答案 1 :(得分：0)
1）你根本不能打破断点吗？通常，一旦需要命中模块或堆栈帧中的代码，它就会得到解决。 2）检查您的pdb是否没有剥离源信息
答案 2 :(得分：0)
执行Build-＆gt; Clean Solution，关闭visual studio，然后重新启动它并进行全新构建。这件事发生在我之前，我认为这似乎解决了它，只是一些过时的pdb信息。
答案 3 :(得分：0)
就我而言，我已经重命名了C ++项目。编译器输出newName.lib，而我的其他项目仍在引用oldName.lib，Build->Clean当然不会删除。
我通过遵循手动清理构建目录的建议找到了这个。随后的链接器unresolved external reference放弃了这种情况。