Is the documentation for WinDbg SRV* wrong?

Question

The documentation says:

If you include the string srv* in your symbol path, the debugger uses a symbol server to get symbols from the default symbol store. For example, the following command tells the debugger to use a symbol server to get symbols from the default symbol store. These symbols are not cached on the local computer.

.sympath srv*

However what I found is the symbols are cached.

I am using WinDbg 10 and the default cache files seem to be created at C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\sym When I delete them and run an executable with path set to srv* the symbols are downloaded here.

So is the documentation wrong?

Farnesol

At least your interpretation has been proved wrong by you. – Indreetloire

Answer 1

Yes, the documentation is wrong (at least for WinDbg 6.2.9200.16384).

You can prove it by entering the mentioned command:

0:000> .sympath srv*
Symbol search path is: srv*
Expanded Symbol search path is: cache*;SRV*http://msdl.microsoft.com/download/symbols

So, as we can see from the output of WinDbg, the expanded symbol path (which will actually be used) contains cache* which indicates that symbols will be cached.

You found this in the documentation for WinDbg, which might not be the correct place to define the behavior, since WinDbg does not load the symbols itself. Instead it uses the dbghelp.dll and the behavior of that DLL might change without the WinDbg help being updated.

---

The symbol path syntax is really hard to get used to and the documentation is spread all over the place. All the magic with expansion and default directories makes it even worse.

The flow is more or less:

1. Split the symbol path at ";" into array elements.
2. For each element in elements:
   1. Switch according to the beginning of the element:
      1. "cache*":
         1. Determine cache path:
            1. If there's a path after the asterisk use that path.
               Otherwise use the default cache path.
            2. Cache symbol from all the following elements in this path.
      2. "symsrv*":
         1. Split element at "*" into (mostly path) components.
         2. The first component is the symbol server DLL to use.
         3. The next components are paths. For each path:
            1. Look for symbol in path. The path can be one of
               • Local directory.
               • UNC.
               • HTTP or HTTPS URL - has to be the last path.
               • Empty string - means the default symbol store. (See SymSetHomeDirectory and !homedir.)
            2. If found:
               1. Copy symbol to all the previous paths in this element.
               2. Finish symbol search
      3. "srv*":
         • Same as "symsrv*symsrv.dll*".
      4. Otherwise:
         1. Treat the element as path and look for the symbol there. (Without the hash etc. like done by symsrv.dll.)

Knowledge

makes sense, even this message DBGHELP: Symbol Search Path: cache*;SRV*https://msdl.microsoft.com/download/symbols also shows cache but what is expanded path really? so srv* is sort of a special path symbol itself? – Farnesol

Totally agree with symbol path syntax is really hard to get used to, it is very confusing and has too many meanings and variations. – Farnesol

You can have more there 3 items separated by asterisks. For example, my symbol path contains (among other things): SRV*D:\Symbols\Microsoft\*\\smb\PublicSymbols\Microsoft\*http://msdl.microsoft.com/download/symbols;SRV*D:\Symbols\Chromium\*\\smb\PublicSymbols\Chromium\*https://chromium-browser-symsrv.commondatastorage.googleapis.com; because I think that it's wasteful for every team member to download an 800MB PDB just for himself instead of sharing it. Another (esoteric) reason is if you use a custom symsrv DLL. – Citizen

@conio: thanks. I was planning to have a generic question about the symbol path syntax and later refer to it. With your edit, that's probably not necessary any more (except maybe for Google reasons). Setting up symbols (#30020389) is one part, but interpreting a symbol path is perhaps still worth its own question. Some examples like yours should be included. – Knowledge

@ThomasWeller: There's still a lot not covered here. For example that when searching "Standard Path Elements" (non-symbol server) searches the given path, then path\symbols and then path\symbols\dll (with dll being the files extensions). I didn't want to change your answer too much or add to much extraneous information. – Citizen

Answer 2

If you use the special cache*path token in your WinDbg symbol path, WinDbg will cache symbols from sources following that token. It's also possible to write srv*localpath*serverpath to cache symbols from serverpath to localpath. If you don't want caching, make sure that your .sympath doesn't include it.

Also, it might be worth it to check if the symbols are effectively cached (fetched once, reused many times) or just stored there for this WinDbg run (fetched once per session).

Endothelioma

It is essentially cached, are fetched only once and it stays there for ever. Subsequent .reloads are fast. If I delete this folder contents than again the .reload is slower when it actually fetches the symbols. – Farnesol