使用WinDbg调试崩溃转储时，映像路径的作用是什么？

到目前为止，我一直将图像路径作为符号路径的一部分，因此我有如下内容：

Symbol search path is: srv*e:\Symbols*http://msdl.microsoft.com/download/symbols;e:\tmp\BackgroundJobEngine

但正确的方法是什么

我应该像今天一样将图像路径作为符号路径的一部分吗

我应该将其作为图像路径传递吗

两者都有

.同情 如果符号路径为

srv*e:\Symbols*http://msdl.microsoft.com/download/symbols;e:\tmp\BackgroundJobEngine

意思是

WinDbg将在

e:\symbols

中搜索符号。如果找到，从那里使用它

如果找不到，它将在Microsoft symbol服务器上查找，下载符号（如果可用），将其存储在e:\symbols中并从那里使用

如果未找到，它将在e:\tmp\BackgroundJobEngine中查找。如果找到，从那里使用它

您的案例中实际发生的情况并不清楚，因为我们不知道您如何存储符号。如果将它们添加到e:\Symbols，例如在生成后步骤中使用

symstore add

，则可执行文件的符号将从e:\Symbols中使用，而e:\tmp\BackgroundJobEngine是无用的

如果您不使用

symstore

，并且您的符号实际上位于e:\tmp\BackgroundJobEngine中，则使用该位置的符号

如果符号信息在可执行文件中（exe可能包含PDB的完整路径），WinDbg也会尝试从那里加载它。如果可执行文件不是在您的计算机上生成的，则可能会由于路径不同而失败，因此添加类似于e:\tmp\BackgroundJobEngine的路径是有意义的

埃克斯帕斯先生 还有一种情况，minidump文件本身不包含可执行文件，以最小化大小，因此WinDbg有一项艰巨的任务：反汇编等

我自己从来没有遇到过这种情况（主要是因为我经常使用.NET，它无论如何都需要完整的内存），但Dmitry Vostokov的《内存转储分析文集收藏版》中给出了一个例子：

1:kd> ub bfabc399
                ^ Unable to find valid previous instruction for 'ub bfabc399'

1:kd> uf driver!ProcessObject
No code found, aborting

---

这可以通过使用

.exepath

命令设置可执行路径来解决。WinDbg随后将从该位置加载程序集本身（不一定是符号）。

Yup，可执行文件的路径。我想知道为什么它有一条专用的路径，我不使用它是否会丢失任何东西。@ThomasWeller你从未见过迷你转储？这很奇怪：）@ussrhero：我的意思是我从未见过可执行文件被剥离的小型转储。没有关系。我的评论被我的回答抛弃了，标准的迷你转储文件不包含任何可执行的图像。您无法注意到这一事实，因为所有标准二进制文件都已上载到microsoft public symbol server。建议的版本是？？或者有文档记录的方式是做cdb-y sympath-i imagepath-z转储文件的推荐？？？/有文档记录的设置sym path的方法是使用Envvar _NT_SYMBOL_path和/或_NT_ALTERNATE_SYMBOL_path，srv*语法指向下存储，并使用symstore或pdbcopy或binpalceSo将您自己的符号添加到该路径，只要我分析.NET进程转储，我就不需要设置专用的exepath，对吗？e:\tmp\BackgroundJobEngine包含与进程相关的*.exe、*.dll和*.pdb文件。我们不使用符号服务器。@马克：对，在这种情况下，您不需要

.exepath

。只要可执行文件中的PDB路径指向e:\tmp\BackgroundJobEngine，您也不需要

.sympath

。您可以尝试不使用它，如果

lm m

显示

专用符号

，则一切正常。exe不引用e:\tmp\BackgroundJobEngine中的PDB。但我有我的答案。谢谢。您可能需要重新加载。在成功执行“uf！”之前，请让windbg沿着映像路径拾取DLL。