Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is the documentation for WinDbg SRV* wrong?

Tags:

c++

windbg

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?

like image 588
zar Avatar asked Jun 28 '16 21:06

zar


People also ask

What are symbol files in WinDbg?

Symbol files are created when images are compiled and are used for debugging an image. They allow someone with the correct tools to view code as the software is running.

How do I download Microsoft symbols?

The easiest way to get Windows symbols is to use the Microsoft public symbol server. The symbol server makes symbols available to your debugging tools as needed. After a symbol file is downloaded from the symbol server it is cached on the local computer for quick access.


2 Answers

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.)
like image 56
Thomas Weller Avatar answered Nov 05 '22 21:11

Thomas Weller


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).

like image 34
zneak Avatar answered Nov 05 '22 21:11

zneak