The breakpoint will not currently be hit. The source code is different from the original version

本文介绍了解决Visual Studio 2005中出现的断点调试问题的方法,包括如何调整调试设置以避免因源代码与编译时版本不匹配而导致的断点失效。

单步调试时出错,原来的断点处显示一个空心圆加一个右下角的警告图标,假如从另一个函数跳入到设置这种无效断点的文件时,便会出现错误的对话框。

 

网上搜了一下原因,有人写:

 

 

昨天对 dnn 跟踪调试的时,设了断点后运行到断点处总提示 “The breakpoint will not currently be hit. The source code is different from the original version” ,搜了一下,原因是:
The problem you're running into is caused by a new feature in the compilers and debugger to keep track of checksums for source files. Using this mechanism we can tell if the source file we're displaying in the debugger matches the original file used to build the application.
When you change a source file while debugging, and Edit and Continue is unavailable or disabled, you'll see warnings about the source not matching. Since Beta 2 we've improved the error message (no longer a Yes/No dialog, just a warning with an OK button). We've also changed the behavior so your breakpoints will no longer show this message when a source file does not match.
To clarify what the message is asking you to do: right-click on the breakpoint in question, and you should see a Location item. On the resulting dialog you should see an override checkbox which will get rid of the message you're seeing when you hover over your breakpoints. Or you could go to Tools->Options->Debugging->General and uncheck the "Require source to exactly match..." option, which will turn off all checksum functionality in the debugger.
偶的英语不太好,大致上看明白了,从菜单栏的 Tools->Options->Debugging->General  
取消 "Require source to exactly match..." 项的选择。
还有两个可能是
1.
打开项目属性,选择调试选项卡,将 启用非托管代码调试 一项钩上。
2.
由于 Terminal Services 这个服务被禁用了,将这个服务设为自动,将这个服务启动。

我试了一下, 确实就好了,下面是另一种方法,但不管用的:

*******************************

Source file: D:/Projects/StereoMatch/stereomatcher.cpp

Module: D:/Projects/StereoMatch/Debug/StereoMatch.exe

Process: [4024] StereoMatch.exe

The source file is different from when the module was built. Would you like the debugger to use it anyway?

*******************************

***********************************

At StereoMatcher.cpp, line 166 ('ComputeCorrespondence()', line 128)

The breakpoint will not currently be hit. The source code is different from the original version.

To allow the breakpoint to be hit when the source code is different, right-click on the breakpoint, choose 'Location ...', and turn on 'Allow the source code to be different from the original version.

To allow this for all breakpoints, disable the option 'Require source files to exactly match the original version' under Tools, Options, Debugging, General'

***********************************

When the compiler generates debug information, it will generate a hash (AFAICT, only MD5 is supported at this point) over all contributing source files (i.e. the .cpp file and all #include'd files). This information along with the full path of the files on the build machine eventually end up in the PDB file.

Now when the debugger tries to obtain a source file, it gets the full path name from the PDB file does some path-based mapping and opens the file. Then it generates the hash and check if it matches the one saved in the PDB.

In your case, it does not and that suggests your source file is outdated. You can force the debugger to ignore such mismatches, but it is obviously a feature designed to prevent you from looking at outdated source files while debugging.

Are you quite certain sources and debug information are from the same version (obviously you could just rebuild on your box to make sure)? May it works if you...

Delete all the files in the folders:

../bin/Debug , ../bin/Release, ../obj/Debug , ../obj/Release, ...obj/Debug/Refactor

For your primary program and the aditional projects in the solution and recompile.

Regards.

If there are any static libraries that you link to, these might be causing the problems. Do you see the problem for all files? Are these files included from precompiled source files (e.g. in static libs)?

There's the dia2dump sample, that might help you understand the problem. You need to build it first. Once you have, you can dump the hash for some of the conflicting files and compare against the real MD5 hash of the source files.

 

最后我还是想办法解决了这个问题,方法是先取消“ Require source files to exactly match the original version ”选项,然后修改一下程序,再在该文件设断点调试一下,然后重新选定“ Require source files to exactly …… ”选项,这样就好了。

最后我想,断点调试失效的原因应该是我当时调试中间的时候顺便改写了程序,导致 Visual Studio 2005 对此进行了记录,而后面好像又强行关掉了 Visual Studio 2005 ,导致记录没有被清除,后面就老是通不过源文件和 debbuger 编译时文件的同步检测。而后面我重新设断点调试和重新选中同步测试选项相当于把错误记录又清除掉了,所以就修复啦。

<think>好的,我现在需要帮助用户解决调试时断点无法命中以及设备在运行时无法设置断点的问题。首先,我需要理解用户的问题。他们可能在开发或调试过程中遇到了断点不触发的情况,这通常出现在设备运行时或者目标环境配置不正确的情况下。 接下来,我应该回忆一下常见的导致断点无法命中的原因。根据经验,可能的原因包括: 1. **符号文件未加载或路径错误**:调试器需要正确的符号文件(如PDB文件)来识别代码位置。如果符号文件缺失或路径不正确,断点可能无法正确绑定。 2. **代码未正确加载或编译优化**:如果代码未被正确部署到目标设备,或者编译时启用了优化(如Release模式),可能导致断点位置与实际执行代码不匹配。 3. **调试器权限或配置问题**:调试器可能需要管理员权限,或者项目配置中的调试设置不正确,比如未启用调试模式、目标架构不匹配等。 4. **断点位置无效**:断点设置在非执行代码行(如注释、空行)或者代码未被执行的路径上。 5. **目标设备连接问题**:设备未正确连接或未被调试器识别,尤其是在远程调试或嵌入式设备场景中。 6. **驱动程序或内核模式调试的特殊要求**:如果是内核模式调试,可能需要特定的命令或配置,如使用`kn`命令查看调用栈[^3]。 现在,我需要结合用户提供的引用内容,特别是引用[3]中提到的使用`kn`命令查看调用栈,这可能涉及内核调试的情况。因此,用户的问题可能出现在驱动程序或内核级代码的调试中。这时需要注意内核调试的特殊性,比如符号服务器的配置、硬件断点的使用等。 接下来,我应该分步骤思考解决方案: **第一步:验证符号文件是否正确加载** 在调试过程中,尤其是内核或驱动程序调试,符号文件至关重要。用户应检查调试器的输出窗口,确认所有相关模块的符号已正确加载。如果出现符号加载失败,需要确保符号路径正确,并且符号文件与代码版本匹配。 **第二步:检查代码优化设置** 用户应确认是否在Debug模式下编译,禁用编译器优化(如GCC的`-O0`或MSVC的`/Od`)。优化可能导致代码被重新排列或删除,使得断点位置无效。 **第三步:确认断点位置有效性** 确保断点设置在可执行的代码行上,避免注释或空行。可以通过反汇编查看实际执行的代码地址是否与断点位置一致。 **第四步:检查调试器配置和权限** 以管理员权限运行调试器,检查项目属性中的调试设置是否正确,比如目标设备类型(本地、远程)、启动命令、调试引擎选择(混合模式、仅本机等)。 **第五步:设备连接和调试模式确认** 对于设备调试,确保设备处于调试模式(如Android的USB调试、iOS的开发模式),并且通过`adb devices`或类似命令识别到设备。如果是内核调试,检查调试电缆连接、波特率设置以及调试器配置是否正确。 **第六步:使用调试命令诊断问题** 在内核调试中,使用`kn`查看调用栈,确认代码执行路径是否符合预期[^3]。此外,`lm`命令可以列出加载的模块,验证驱动是否已正确加载。如果断点在内核代码中,可能需要使用硬件断点(`ba`命令)而非软件断点。 **第七步:检查代码修改和部署流程** 确保修改后的代码已成功编译并部署到目标设备。有时重新生成解决方案或清理后重新部署可以解决因旧版本代码残留导致的问题。 **第八步:处理特定于框架的问题** 参考引用[2]中提到,某些框架(如Unreal Engine)可能限制了直接访问内部变量,需使用官方提供的接口。如果项目涉及流式加载或级别可见性,错误的API调用可能导致代码未按预期执行,进而影响断点命中。 **第九步:验证示例代码和环境配置** 用户提到引用了示例代码(如EchoEvtDeviceAdd),需确认示例项目的配置是否与当前环境一致,特别是输入设置和设备识别部分[^2][^3]。例如,确保启用了手势识别器的输入设置,避免因配置缺失导致设备未正确初始化。 最后,综合以上步骤,整理出一个结构化的解决方案,帮助用户逐步排查问题。同时,生成的相关问题需要覆盖调试技巧、配置优化、工具使用等方面,以帮助用户深入理解调试过程中可能遇到的其他挑战。</think>### 分步解决方案 #### **步骤1:验证符号文件加载状态** - 在调试器输出窗口检查符号加载日志,确保所有模块的.pdb文件路径正确 - 使用WinDBG时执行命令:`!sym noisy` 和 `.reload /f` 强制重新加载符号[^3] - 示例错误现象:`*** WARNING: Unable to verify checksum for MyDriver.sys` #### **步骤2:禁用编译器优化** - Visual Studio项目属性 → C/C++ → 优化 → 禁用优化(/Od) - 检查编译输出是否包含调试信息:`/Zi`(调试信息)和 `/DEBUG`(生成PDB) - 对于内核驱动,确认INF文件中包含`KMDF_VERSION_1.31`等正确框架版本声明[^2] #### **步骤3:断点有效性验证** - 在Visual Studio中右键断点 → 位置 → 查看反汇编确认地址有效性 - 使用WinDBG时: ```bash bp MyDriver!DriverEntry # 设置软件断点 ba e1 MyDriver!IoControl # 设置硬件执行断点[^3] ``` #### **步骤4:调试器权限与配置** - 以管理员身份运行Visual Studio - 检查调试器附加选项: ```xml <!-- .vcxproj文件配置示例 --> <LocalDebuggerCommand>%SystemRoot%\System32\verifier.exe</LocalDebuggerCommand> <DebuggerType>Mixed</DebuggerType> ``` #### **步骤5:设备连接诊断** - 执行设备管理器操作: ```powershell devcon status *VEN_1234* # 检查设备状态 bcdedit /debug on # 启用Windows调试模式 ``` - 对于USB调试,使用`USBView.exe`工具验证设备描述符 #### **6. 内核调试特殊处理** - 在WinDBG中验证驱动加载: ```bash lmDvM MyDriver # 显示驱动模块详情 !process 0 0 # 列出所有进程[^3] ``` - 使用`ed nt!Kd_Default_Mask 8`启用调试输出 #### **7. 框架兼容性检查** - 对照引用[2]检查代码规范: ```cpp // 错误方式(直接访问内部变量): if (CurrentLevelPendingVisibility) {...} // 正确方式(使用API): ULevelStreaming* Level = GetWorld()->GetStreamingLevels()[0]; Level->SetShouldBeVisible(true);[^2] ``` ###
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值