即使为 dll 加载了调试符号，也不会为文档加载调试符号
我已经构建了一个带有调试信息的特定 dll（编译器选项 /Zi 和链接器选项 /DEBUG）。通过主程序中的中断语句，我启动了Visual Studio进行调试。在“调试”->“Windows”菜单中显示的模块列表中，我可以看到已为感兴趣的 dll 加载了符号。但是，当我从该 dll 打开 C++ 文件并尝试设置断点时，它说调试符号不可用于该文档。毫无疑问，这个 C++ 文件被编译到该 dll 中，并且它与用于构建 dll 的源相同（我只这样做了）。为什么会出现这种情况？在我开枪自杀之前，请帮忙。
I have built a particular dll with debug information (compiler option /Zi and linker option /DEBUG). Through an interrupt statement in the main program, I launched the Visual Studio for debugging. In the list of modules shown as seen from Debug->Windows menu, I could see that the symbols have been loaded for the dll interested in. However when I open a C++ file from that dll and try to set a breakpoint, it says debug symbols are not available for the document. There is no question that this C++ file was compiled into that dll, and that it is the same source used to build the dll (I only did it). Why does this happen? Please help, before I shoot myself.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我没有明确的答案，只有一些建议。
有时 mdm.exe（机器调试管理器）会停止正常工作。终止该进程并重新启动 Visual Studio 会有所帮助。如果重新启动后问题仍然存在，那么这可能不是原因。
未来的源文件时间（最后修改时间）可能会导致各种奇怪的问题。要检查文件时间，您可以不搜索任何内容 (Windows XP) 或搜索“*”(Windows 7)。这将列出所选文件夹中的所有文件。然后按日期对结果进行排序以查看最大/最短文件时间。我不知道错误的文件时间从何而来 - 我只知道这种情况时常发生。可能是 Visual Studio 本身，也可能是我正在使用的其他工具。
您可以尝试在 DLL 项目已打开的情况下从 Visual Studio 启动使用 DLL 的应用程序。为此，请打开“配置属性”，选择“调试”页面，然后输入应启动的 .exe（如果需要，请+参数）。然后像启动 .exe 项目一样启动调试会话。
解决 Visual Studio 的许多问题的方法是手动“清理”项目，然后进行完整的重新编译。删除构建过程中生成的或存储解决方案或项目“选项”的所有文件。即所有 .suo .ncb .user 文件以及“中间”和“输出”文件夹中的所有内容。如果您使用源代码控制，只需将整个项目从源代码控制系统检索到一个干净的目录中，然后从头开始重新构建。 （从源代码管理中获取“新鲜”的所有内容还可以解决任何潜在的文件时间问题 - 至少对于不保留文件时间的源代码控制系统）
另一个可能的原因是，VS 加载了错误的 . pdb 文件。可以在为 VS 配置的符号服务器/符号目录（或通过 _NT_SYMBOL_PATH 变量在系统范围内）或 VS 符号缓存目录中找到具有匹配名称的 .pdb 文件。具有匹配名称的 .pdb 文件如何出现在这样的地方是另一回事，但可以轻松检查是否加载了错误的 .pdb 文件：删除构建生成的 .pdb 文件，然后启动调试会话。如果 VS 跟踪有问题的 .exe/.dll 的“已加载符号”，则它一定在其他位置找到了 .pdb 文件。
有时 VS 似乎会以某种方式弄乱断点位置。我不完全知道这种情况何时或如何发生，但症状之一是，如果删除一些断点，它们会在启动下一个调试会话时神奇地重新出现。我发现设置一个新断点，然后通过“调试/删除所有断点”删除所有断点，然后重新设置所需的断点会有所帮助。
I don't have a definitive answer, only a few suggestions.
Sometimes mdm.exe (Machine Debug Manager) stops to work properly. Terminating the process and re-starting Visual Studio helps. If the problem persists between reboots however that probably isn't the cause.
Source-file-times (last modified) that are in the future can cause all kind of weird problems. To check file times, you can do a search for nothing (Windows XP) or "*" (Windows 7). That will list all files in the selected folder. Then sort the result by date to see the max/min file time. I have no idea where the incorrect file-times come from - I just know that it happens from time to time. Might be Visual Studio itself, might be some other tool I'm using.
You could try to start the application that uses your DLL from Visual Studio, with your DLL project already open. To do that, open the "Configuration Properties", select the "Debugging" page, and enter the .exe that should be started (+ arguments if you need any). Then start the debug session as you would for a .exe project.
A cure for many problems with Visual Studio is to "clean" the project manually, and do a full re-compile. Delete all files that are generated during a build process or that store solution or project "options". i.e. all .suo .ncb .user files plus everything in the "intermediate" and "output" folders. If you're using source control, just retrieve the whole project from your source control system into a clean directory, and re-build from scratch. (Getting everything "fresh" from source control also takes care of any potential file-time problems - at least with source control systems that don't preserve file-times)
Another possible reason would be, that VS loads the wrong .pdb file. A .pdb file with a matching name could be found in a symbol server/symbol directory configured for VS (or system wide through the _NT_SYMBOL_PATH variable), or in the VS symbol cache directory. How a .pdb file with a matching name came to be in such a place is a different story, but one can easily check if the wrong .pdb file is loaded: delete the .pdb file generated by the build, and start a debug session. If VS traces "symbols loaded" for the .exe/.dll in question, it must have found a .pdb file in some other location.
Sometimes VS seems to mess up breakpoint locations in some way. I don't exactly know when or how this happens, but one of the symptoms is, that if one deletes some breakpoints, they magically reappear when starting the next debug-session. I found that setting a new breakpoint, then deleting all break points by Debug/Delete All Breakpoints, and the re-setting the required ones helps.
1）你根本无法到达断点吗？一般来说，一旦需要命中模块或堆栈帧中的代码，它就会得到解决。
2）检查你的pdb是否没有源信息被剥离
1) Are you not able to hit the breakpoint at all ? Generally, it gets resolved once the code in the module or stack frame needs to be hit.
2) Check if your pdb is not source information stripped
执行“构建->清理解决方案”，关闭 Visual Studio，然后重新启动它并进行全新构建。这种情况以前发生在我身上一次，这似乎解决了它，我想只是一些过时的 pdb 信息。
Do a Build->Clean Solution, close visual studio and then restart it and do a fresh build. This happened to me once before, and that seemed to fix it, just some outdated pdb information, I suppose.
就我而言，我已重命名 C++ 项目。编译器正在输出
newName.lib，而我的其他项目仍在引用oldName.lib，它当然不会被Build->Clean删除代码>.我通过遵循手动清理构建目录的建议发现了这一点。随后的链接器
未解析的外部引用泄露了这种情况。In my case, I had renamed the C++ project. The compiler was outputting
newName.libwhile my other projects were still referencingoldName.libwhich of course would not be removed by aBuild->Clean.I found this out by following the advice to manually clean the build directory. The subsequent linker
unresolved external referencegave away the situation.