# [Lldb-commits] [PATCH] D55142: Minidump debugging using the native PDB reader

Leonard Mosescu via lldb-commits lldb-commits at lists.llvm.org
Tue Dec 11 14:12:20 PST 2018

>
> The Windowsy thing to do is what Zach said:  Check the directory that
> contains the .dmp for the .pdb.  It's the first place the VS debugger looks
> when opening a minidump.  It's less sensitive to the user's environment.
> (Making the user change the current working directory for this could be at
> odds with other bits of the software that look relative the cwd.)
>
> https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Find_binaries__symbol___pdb__files__and_source_files
>

Except that it doesn't :) Neither VisualStudio nor the Windows Debuggers
(windbg & co) look for PDBs in the same directory as the dump file. The
search is controlled by an explicit "symbol search path". The link you
mentioned is a bit confusing indeed (although it only claims that the
.exe's are searched in the same directory as the .dmp)

While security is not a big issue here, note that Windows generally
> searches for DLLs in the known/expected places _before_ checking to see if
> it's in the current working directory.  This prevents a sneaky download
> from effectively replacing a DLL.  Replacing a PDB is probably less of a
> concern.
>
>

On Tue, Dec 11, 2018 at 1:28 PM Adrian McCarthy <amccarth at google.com> wrote:

> It's really frustrating how the email discussion doesn't always make it to
> Phabricator.
>
> The Windowsy thing to do is what Zach said:  Check the directory that
> contains the .dmp for the .pdb.  It's the first place the VS debugger looks
> when opening a minidump.  It's less sensitive to the user's environment.
> (Making the user change the current working directory for this could be at
> odds with other bits of the software that look relative the cwd.)
>
>
> https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Find_binaries__symbol___pdb__files__and_source_files
>
> While security is not a big issue here, note that Windows generally
> searches for DLLs in the known/expected places _before_ checking to see if
> it's in the current working directory.  This prevents a sneaky download
> from effectively replacing a DLL.  Replacing a PDB is probably less of a
> concern.
>
>
>
> So I +1 Zach's proposal.
>
> On Tue, Dec 11, 2018 at 12:07 PM Leonard Mosescu <mosescu at google.com>
> wrote:
>
>> I think as combination of explicit symbol search path + something similar
>> to Microsoft's symsrv would be a good "real" solution (and yes, that would
>> be packaged as a SymbolVendor, outside SymbolFilePDB)
>>
>> For short term, I don't see a clearly superior alternative to searching
>> the current directory.
>>
>> On Tue, Dec 11, 2018 at 12:02 PM Pavel Labath <pavel at labath.sk> wrote:
>>
>>> On 11/12/2018 20:34, Zachary Turner wrote:
>>> > I meant the location of the minidump.  So if you have C:\A\B\C\foo.dmp
>>> > which is the dump file for bar.exe which crashed on another machine,
>>> > then it would look for C:\A\B\C\bar.pdb.  That actually seems like
>>> > fairly intuitive behavior to me, but maybe I'm in the minority :)
>>> >
>>> > We can see what Pavel, Adrian, and others think though or if they have
>>> > any other suggestions.
>>> >
>>>
>>> It sounds like there is a precedent for searching in CWD. I don't know
>>> how useful it is (I traced it back to r185366, but it is not mentioned
>>> there specifically), but it is there, and I guess it's not completely
>>> nonsensical from the POV of a command line user.
>>>
>>> I guess we can just keep that there and not call it a hack (though, the
>>> fact that the searching happens inside SymbolFilePDB *is* a hack).
>>>
>>> Searching in the minidump directory would also make sense somewhat, but
>>> I expect you would need more plumbing for that to happen (and I don't
>>> know of a precedent for that).
>>>
>>> pl
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20181211/9e24d867/attachment-0001.html>