1. 静态检查
windbg 调试工具包中有一个工具symchk.exe, 选项很多, 下面一个简单的用法可以检查一个 test.exe能不能找到与它匹配的PDB:
这是成功的情形. 下面来个失败的作为对比:
2. 如果已经在windbg内部, 可以通过下面的命令检查
最后一行说 MATCH, 肯定没问题.
3. 在windbg中(在VS中不行), 如果你100%确信源代码没有任何改动, 只不过被重新编译了一下.
可以通过 .symopt +40 来关闭对GUID的强行检查. 从而load一个不匹配的PDB.
4. 除了1中提到的工具, 还有一个叫chkmatch 的工具, 在
http://www.debuginfo.com/download/chkmatch.zip
可以下载, 该工具不仅可以检查是否匹配, 还可以把不匹配的强制改为匹配, 也就是说EXE/DLL和PDB中的GUID相同, 这样在VS中就可以使用了, 当然, 高度危险, 后果自负.
5. 在VS中的空心圆
我同事把那种设置了断点之后, 没有设置成功, 出现的红色圆圈叫做空心圆问题.
此类问题有两个可能的原因:
(A) 的确PDB不匹配
(B) 时机还不到, 有些源文件对应的module本身还没有被load, 对应的PDB更不会被load了.
(C) 代码被优化掉了
对于(B)的情况, 在windbg中也同样会出现断点貌似设置不对的情况.
对于是(A)还是(B)的判断, 在VS中, 可以打开Module 窗口, 这个窗口对诊断此类问题很有帮助. 在Debug菜单下, 有些VS2005 安装之后, 在DEBUG菜单下找不到这个菜单项, 不要惊慌, 它只是没出现在菜单项而已, 通过tools-customize可以找回它.
这个Module窗口中, 清楚地列出当前被调试的进程中, 有哪些module, 每个module的pdb 情况, 你还可以手工load一个module对应的symbol文件, 可以查看symbol文件的细节.
在这个窗口中, 一个可能会令你迷惑的地方是: 对于mixed module, 它会被列出两次, 一次为native, 一次为.NET
6 关于5中的(C)的情况, 代码被优化掉了, 有几个应对办法:
(I) 如果可以, 重新编译, 关闭优化, 我个人的经验和习惯是, 永远不打开优化, 除非: 有证据表明某处有性能问题, 或在为RISC CPU写程序, 此类指令集的性能高度依赖于是否优化.
(II) 对于.NET 程序, 你尽早会碰到即使关闭了编译优化, 也仍然被提示说不能evaluate 表达式, 或断点设不上的问题, 这是另一种优化. JIT, 关闭它可以通过以下一个不广为人知的办法:
若模句是 test.exe
在它同一目录下, 产生一个test.ini的文件. 内容固定如下:
[.NET Framework Debugging Control] GenerateTrackingInfo=1 AllowOptimize=0
这会禁用JIT优化, 条件是, 下次启动程序时才会生效.
7. bash脚本(cygwin下测试通过) 得到GUID
# $1: exe/dll/pdb file # $2: the target string # $#: the offset of guid to $2 function get_guid() { exe_fname="$1" guid_mark_string=$2 guid_offset=$3 regex="$(echo -n $guid_mark_string | od -t x1 | sed ‘s/[^ /t]* /?//;s/ ///n/g‘)" byte_offset=$(od -v -t x1 $exe_fname | sed ‘s/[^ /t]* /?//;s/ //n/g; /^$/d‘ | grep -b -P "$regex" | head -1 | sed ‘s/:.*//‘) od -v -t x1 -j $((byte_offset/3+ guid_offset)) $exe_fname -N 16 | head -1 | sed ‘s/[^ /t]* //‘ } function get_guid_from_module() { get_guid $1 "RSDS" 4 } function get_guid_from_pdb() { get_guid $1 "/LinkInfo" -20 }
http://blackjazz07.blog.163.com/blog/static/16249081820129311077569/