WinDbg入门：符号加载和调用栈查看

WinDbg的入门用法可以抓住一条主线：先让调试器拿到正确的目标和符号，再从异常线程、调用栈和模块信息里缩小问题范围。分析转储文件就打开 .dmp，分析正在运行的程序则启动或附加目标进程。无论哪一种，符号没有加载好，后面的地址和栈帧都很难读懂。

用一次实际会话熟悉WinDbg

1、启动目标并确认调试器已停住

打开WinDbg后，可在【File】→【Launch Executable】启动一个测试程序，也可以打开已有转储文件。目标刚附加或启动后，命令窗口会显示模块加载和当前提示符。确认目标确实是要分析的进程或转储，不把第一屏地址当成故障结论。

2、设置符号路径并重新加载

在命令窗口输入 .sympath srv* 设置符号搜索路径，再执行 .reload 让WinDbg开始查找并加载符号。微软组件可使用公共符号服务，自家程序还要把构建时生成的PDB所在目录加入符号路径。函数名仍然显示不完整，就用 .reload /f 重新尝试，并检查转储、二进制文件和PDB是否来自同一版本。

3、让程序继续运行，再查看调用栈

断点设好后，执行 g 让程序继续运行。断点命中或异常中断后，输入 k 查看当前线程的调用栈。栈顶对应当前停下的位置，向下的帧展示调用经过的函数。确认当前线程或横向比较线程，可先用 ~ 列出线程，再切换线程后重新执行 k。

4、结合模块和异常分析继续定位

输入 lm 可以查看已加载模块及其符号状态，适合核对某个DLL、驱动或可执行文件是否出现在异常附近。程序崩溃后可运行 !analyze -v 获取更详细的异常分析。它提供异常代码、相关栈帧等线索，但不能替代对源码、版本和复现步骤的验证。

怎样判断这轮分析有没有价值

符号正常加载后，调用栈中会出现可识别的模块和函数名，而不是一串无法对应的地址。此时把异常线程、最靠近异常的栈帧、lm 里的模块版本和 !analyze -v 的异常代码一起记录下来，再回到对应版本的源码或驱动变更中验证。

调用栈每次都不同、模块大量显示为deferred，或函数名始终缺失，优先处理符号和版本匹配问题。栈帧稳定落在同一个自家函数，就检查该函数的参数、对象状态和调用路径。问题总在某个第三方模块附近出现，就记录其版本，并在测试环境中用更新、回退或禁用的方式复现和比对。这样得到的是可继续验证的线索，而不是把WinDbg的自动输出当成最终结论。