我经常帮开发者解决这类旧C#程序的调试定位问题，当报错堆栈的行号和当前源码对不上时，核心是要利用pdb调试符号文件里保存的原始编译映射信息，一步步还原出exe中实际引发问题的代码位置。下面是具体的操作步骤，亲测有效：

这是最关键的前提！如果pdb不是和当前exe一起编译生成的，所有的行号映射都是错的。验证方法：

• 用VS的调试模块窗口：启动调试加载exe后，打开“模块”窗口（调试→窗口→模块），找到你的exe，看“符号状态”是否显示“已加载”，如果提示不匹配，就得去找对应版本的pdb。
• 用命令行工具验证：运行dumpbin /headers YourApp.exe和dumpbin /headers YourApp.pdb，对比输出里的“时间戳”和“签名”，必须完全一致才是匹配的。

pdb里保存了编译时IL代码和原始源码行号的对应关系，我们可以用工具把它解析出来：

方法1：用SOS调试扩展（适合.NET Framework/.NET Core） #

1. 把exe和pdb放在同一目录，打开命令提示符，运行dotnet-dump analyze YourApp.exe（.NET Core/.NET 5+），如果是.NET Framework，用windbg加载exe后进入调试会话。
2. 加载SOS扩展：.NET Core直接输入.load sos；.NET Framework输入.loadby sos clr。
3. 从堆栈追踪里拿到出错方法的指令指针（IP）地址，比如堆栈里的YourNamespace.YourClass.YourMethod() + 0x123，把基地址加上0x123得到完整IP。
4. 输入!ip2md [完整IP地址]，得到该方法的元数据令牌。
5. 再输入!line -m [元数据令牌]，就能看到这个方法里所有IL偏移对应的原始编译时的源码行号和文件路径——这就是你要找的exe对应的原始行号！

方法2：用ildasm工具（简单直观） #

1. 打开Visual Studio自带的ildasm（路径一般是C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\ildasm.exe）。
2. 加载你的exe，找到出错的方法双击打开。
3. 在弹出的窗口里，勾选“显示行号”选项，就能看到每一行IL代码旁边对应的原始源码行号。虽然看不到源码内容，但你可以拿着这个行号去查找当时的源码版本。

既然当前源码行号不对，说明源码已经被修改过，你需要定位到编译这个exe时的源码快照：

• 如果用了Git/SVN等版本控制：可以用pdbgit工具（针对Git），它能直接从pdb里提取编译时的Git提交哈希，然后用git checkout [哈希值]就能切换到当时的源码版本，直接查看对应行号的代码。
• 如果没有版本控制：就拿着第二步得到的原始行号，在当前源码里找逻辑最匹配的代码段，结合ildasm看到的IL代码逻辑（比如调用的方法、赋值操作）来推断原始代码的内容。

嫌上面步骤麻烦？可以用反编译工具直接搞定：

• 用dnSpy加载exe和pdb：它会自动关联pdb里的原始行号，反编译后的代码会显示编译时的行号，而不是当前源码的行号。你可以直接看到exe里的代码对应的原始行位置，甚至能断点调试验证。
• 用ILSpy：同样加载exe和pdb，在反编译选项里勾选“显示行号”，就能看到原始编译时的行号，对比当前源码就能找到差异。

• 必须用原始编译生成的pdb，重新编译生成的pdb和旧exe不匹配，没用。
• 如果pdb是“公共pdb”（一般是发布版本的pdb，只包含有限信息），可能无法拿到完整的行号映射，这种情况只能靠反编译IL代码来推断逻辑。

内容的提问来源于stack exchange，提问作者user31673