SymbolReader doesn't allow UNC symbol server paths

[Zhentar]

SymbolReader.GetServerSymbolStore does not allow the use of UNC paths as symbol stores.

The code responsibe:

diagnostics/src/SOS/SOS.NETCore/SymbolReader.cs

Line 1117 in 367aa5c

if (!Uri.TryCreate(symbolServerPath, UriKind.Absolute, out Uri uri) || uri.IsFile)

I suppose that perhaps the uri.IsFile was intended to check if the URI referred to a file rather a directory, but that is not what IsFile indicates:

> (new Uri(@"\\my_network\symbolstore")).IsFile
true

[mikem8361]

Looks like I should also check if !url.IsUnc.

The SymStore code has the same check in The HttpSymbolStore constructors. It will need the same change.

[Zhentar]

Why do local paths need to be excluded at all? I have hundreds of local folders that are legitimate symbol stores (mostly along the lines of srv*D:\xperf\Bug12345_Repro.etl.NGENPDB)

[mikem8361]

The sympath parsing does support directories and UNC paths, but as far as I can tell from the docs directory paths are not prefixed with "srv*".

.sympath D:\xperf\Bug12345_Repro.etl.NGENPDB

Should work. SRV* is for symbol servers and you can also specify a cache for the server like:

 .sympath srv*c:\MyServerSymbols*https://msdl.microsoft.com/download/symbols

[Zhentar]

There are more or less two variants of symbol lookup...

1. Old-fashioned, no-symsrv way:

PS C:\Program Files (x86)\Windows Kits\10\Debuggers\x64> .\symchk.exe C:\Windows\System32\combase.dll /v /s "C:\othersym"
[SYMCHK] Searching for symbols to C:\Windows\System32\combase.dll in path C:\othersym
DBGHELP: Symbol Search Path: C:\othersym
[SYMCHK] Using search path "C:\othersym"
DBGHELP: No header for C:\Windows\System32\combase.dll.  Searching for image on disk
DBGHELP: C:\Windows\System32\combase.dll - OK
DBGHELP: C:\othersym\combase.pdb - file not found
DBGHELP: C:\othersym\dll\combase.pdb - file not found
DBGHELP: C:\othersym\symbols\dll\combase.pdb - file not found

2. The symsrv way:

PS C:\Program Files (x86)\Windows Kits\10\Debuggers\x64> .\symchk.exe C:\Windows\System32\combase.dll /v /s "srv*C:\othersym"
[SYMCHK] Searching for symbols to C:\Windows\System32\combase.dll in path srv*C:\othersym
DBGHELP: Symbol Search Path: srv*C:\othersym
[SYMCHK] Using search path "srv*C:\othersym"
DBGHELP: No header for C:\Windows\System32\combase.dll.  Searching for image on disk
DBGHELP: C:\Windows\System32\combase.dll - OK
SYMSRV:  BYINDEX: 0x1
         C:\othersym
         combase.pdb
         28C4EF2E3A6DD5EA0CBCA4163A6505321
SYMSRV:  UNC: C:\othersym\combase.pdb\28C4EF2E3A6DD5EA0CBCA4163A6505321\combase.pdb - path not found
SYMSRV:  UNC: C:\othersym\combase.pdb\28C4EF2E3A6DD5EA0CBCA4163A6505321\combase.pd_ - path not found
SYMSRV:  UNC: C:\othersym\combase.pdb\28C4EF2E3A6DD5EA0CBCA4163A6505321\file.ptr - path not found
SYMSRV:  RESULT: 0x80070003

Because the NGENPDB folders include symbols in the format of {pdbFilename\{signature}{age}\{pdbFilename}, a srv*-less symbol path will result in failed symbol lookups.

Note that casual testing, e.g. .sympath C:\symbols will likely fail to reproduce this behavior - because dbghelp checks for a pingme.txt file in the root folder for drive & UNC paths, and automatically inserts a srv* star if it's present.

There are also quite a few other potential subtleties to symsrv paths, detailed here: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/advanced-symsrv-use . Things like symsrv*symsrv.dll**\\network\symbol_cache*https://msdl.microsoft.com/download/symbols are perfectly legal (and there could even be alternative symsrv implementations that take non-path input!)

[mikem8361]

I have a fix (will merge it soon) for supporting UNC paths as "servers" with the {pdbFilename\{index}\{pdbFilename} directory structure. Hopefully that is enough for your scenarios. The sympath support in SOS isn't going to handle all the subtleties that symsrv/windbg can especially things like custom symbol server dlls (they wouldn't work for portable PDBs anyway). It is meant for setting up fairly simple symbol search paths for portable PDBs. Any failures will not affect windbg's symbol searching.

[mikem8361]

PR #690