关于PDB与EXE/DLL 文件的匹配问题

1. 静态检查
windbg 调试工具包中有一个工具symchk.exe, 选项很多, 下面一个简单的用法可以检查一个 test.exe能不能找到与它匹配的PDB:

这是成功的情形. 下面来个失败的作为对比:

2. 如果已经在windbg内部, 可以通过下面的命令检查

最后一行说 MATCH, 肯定没问题.

3. 在windbg中(在VS中不行), 如果你100%确信源代码没有任何改动, 只不过被重新编译了一下.
可以通过 .symopt +40 来关闭对GUID的强行检查. 从而load一个不匹配的PDB.

4. 除了1中提到的工具, 还有一个叫chkmatch 的工具, 在

可以下载, 该工具不仅可以检查是否匹配, 还可以把不匹配的强制改为匹配, 也就是说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
}