<div dir="ltr"><div dir="ltr"><div dir="ltr">It's really frustrating how the email discussion doesn't always make it to Phabricator.<div><br></div><div>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.)</div><div><br></div><div><a href="https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Find_binaries__symbol___pdb__files__and_source_files">https://docs.microsoft.com/en-us/visualstudio/debugger/using-dump-files?view=vs-2017#BKMK_Find_binaries__symbol___pdb__files__and_source_files</a><br></div><div><br></div><div>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.</div><div><br></div><div><a href="https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications">https://docs.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications</a><br></div><div><br></div><div>So I +1 Zach's proposal.</div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 12:07 PM Leonard Mosescu <<a href="mailto:mosescu@google.com">mosescu@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">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)<div><br></div><div>For short term, I don't see a clearly superior alternative to searching the current directory.</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 11, 2018 at 12:02 PM Pavel Labath <<a href="mailto:pavel@labath.sk" target="_blank">pavel@labath.sk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 11/12/2018 20:34, Zachary Turner wrote:<br>
> I meant the location of the minidump.  So if you have C:\A\B\C\foo.dmp <br>
> which is the dump file for bar.exe which crashed on another machine, <br>
> then it would look for C:\A\B\C\bar.pdb.  That actually seems like <br>
> fairly intuitive behavior to me, but maybe I'm in the minority :)<br>
> <br>
> We can see what Pavel, Adrian, and others think though or if they have <br>
> any other suggestions.<br>
> <br>
<br>
It sounds like there is a precedent for searching in CWD. I don't know <br>
how useful it is (I traced it back to r185366, but it is not mentioned <br>
there specifically), but it is there, and I guess it's not completely <br>
nonsensical from the POV of a command line user.<br>
<br>
I guess we can just keep that there and not call it a hack (though, the <br>
fact that the searching happens inside SymbolFilePDB *is* a hack).<br>
<br>
Searching in the minidump directory would also make sense somewhat, but <br>
I expect you would need more plumbing for that to happen (and I don't <br>
know of a precedent for that).<br>
<br>
pl<br>
</blockquote></div>
</blockquote></div>