- TL; DR
- Detailed Instructions and Tips
- Install the Debugging Tools for Windows (if you don’t already have them)
- In Process Explorer, select
Options | Configure Symbols...and configure as below:
Here are the paths for you to copy and paste—first the Dbghelp.dll path, then the Symbols path:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll srv*d:\symbols*https://msdl.microsoft.com/download/symbols
Above is a Symbols path with the symbol cache (
d:\symbols) on the
d: drive. Below is for the
Select the local symbols cache folder you wish to have for your system as necessary (
d:\symbols between the two asterisks above).
c: drive is short on space, so I use my larger
d: drive for my local symbols instead. You could use
c:\symbols (second path above) or whatever.
The local symbols can get pretty big, many gigabytes.
This is my setup, and works for me, with the Windows Driver Kit (WDK) installed as well as the Software Development Kit (SDK) with the Debugging Tools for Windows installed after the WDK too. NOTE: The Dbghelp.dll path is different from the paths I have seen in older articles, which do not work on my computer.
I am following along in Windows Internals, Part 1, Edition 7 by Mark Russinovich, et. al. The book uses Sysinternals Process Explorer application heavily and discusses how to enable debugging symbols downloads via the Microsoft symbol server to enable resolution of raw address offsets in executables to symbolic names, for instance, in the Threads tab of a process’s Properties dialogue box or in stack traces.
However, I was not having much success getting it to work. His screenshot was correct, but the link he gave for information had an old windbg.dll path, and other articles on the web were also outdated or did not give the windbg.dll path at all. That is what threw me.
I did not see the screenshot, just the link. I finally made it work, and came to understand why it was not working, so I thought I would explain it here for the benefit of others and give some detailed insights into how to know whether it is truly working or not.
Detailed Instructions and Tips
First, open up the
Options | Configure Symbols... dialogue box in Process Explorer:
This is what the dialog box looks like the first time you use it:
Note that the Symbols path is empty, and the default path to
dbghelp.dll is in the
C:\Windows\System32 subdirectory, which will not work.
Configuring the Dbghelp.dll Path
First, lets tackle the dgbhelp.dll path. The initial value for that path shown above points to a version of that dll that will not work. You will need to do some work to get the right version of the dll and point to it.
Debugging Tools for Windows
If you have not already, you will need to get a copy of the dgbhelp.dll that comes with the Debugging Tools for Windows. This immediately preceding link explains how to install those tools for Windows 10. Distilled, the steps are basically:
- Either install the Software Development Kit, including selecting the Debugging Tools for Windows
- Or, install only the Debugging Tools for Windows by installing the SDK but selecting Debugging Tools for Windows and deselecting everything else
- Or, install the Windows Driver Kit
The Right dgbhelp.dll Path
Now, you need to point to the right dbghelp.dll file. You can either paste the following path into its input box:
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll
Or click on the ellipsis button to the right of the Dbghelp.dll path input box and navigate to the above path and select
If you paste the path, I would still navigate to it to make sure it is correct for your machine (perhaps your OS drive is
d:?). The dialogue box should now look like this:
Update the Symbols Path
The Symbols path has the following form, taken from the Microsoft Docs Debugging with Symbols Page:
srv*[local cache]*[private symbol server]*https://msdl.microsoft.com/download/symbols
I use the following Symbols path for my needs:
I do not use a private symbol server, and my
d: drive is larger than my small
c: drive, so the path to my local symbol cache (between the asterisks)
d:\symbols. You could use
c:\symbols or wherever else is appropriate for you.
Make sure the path is valid and the directory for the symbols exists. Also, the symbol cache can get quite large (many gigabytes), so make sure you have enough space on the drive.
The Final Configuration
Fully configured, my setup looks like this (just like the screenshot in Windows Internals, Part 1, Edition 7 I missed!):
Articles with the Old Path
Note that I do not have the following Dgbhelp.dll path on my computer, which the older articles point to for the location of debugging tools:
c:\Program Files\Debugging Tools for Windows\...
Articles that use that path for locating the
dbghelp.dll seem to be out of date.
See if It All Works
Now, we need to see if everything is working as desired.
Check the Process’ Properties
Here is a screenshot of Process Explorer with the
searchui.exe process highlighted (fourth from the top in dark blue). I will use it in my examples:
Right click on a Windows process, and select Properties:
After the properties dialogue box comes up, select the Threads tab at the top:
Not Yet Working
Before configuring symbols correctly, the output looks something like this:
Note how the symbols are not resolved - in the highlighted line, you see the following for the start address of thread 9384:
The symbol is not resolved - you just see the offset of the function as a hexadecimal number (0x120cd0) after a plus sign.
Below, you see the symbol server is working and the offset is resolved to a symbolic name (function name):
Now, we see not just the offset, but the actual function name:
Note that, especially at first, there may be a delay as the symbols are acquired from the Microsoft symbol server. Be patient. The symbols will automatically fill in as they are acquired. Let me emphasize that: be very patient! It may take a while until they start filling in, and you may think it is broken prematurely. In my experience, it has never taken more than 2-3 minutes to start going, but that can seem like a long time when just staring at the dialog box.
Check Stack Trace
You can also click the Stack button to see a stack trace:
Stack trace without full symbols:
Stack trace with full symbols:
Check the Symbols Folder
Another way to verify explicitly that the symbol server functionality is working is to just go look at the local cache folder
d:\symbols in my case) with file explorer and see if it contains files and folders. If it is empty after viewing the threads
in a process’ properties dialogue box for an appropriate amount of time, something is wrong.
As discussed here, setting up a Symbols Path environment variable
_NT_SYMBOL_PATH, which uses the same
format as above, can be very useful for Windows debuggers (WinDbg, Visual Studio, etc.) in certain situations.
However, the environment variable setup did not seem to work for Process Explorer, but when I opened a debug session in Visual Studio, it populated the symbol cache, so it was working for other programs.
Also, a gotcha: I noticed when I set up the Symbols Configuration in Process Explorer when not started as with Administrator privileges, when I did start it with Administrator privileges, I had to reconfigure the Symbol Configuration - it had gone back to the initial configuration. So, that might be a potential problem to watch out for.
The Microsoft Symbol Server path and Symbols path format has not changed form in quite some time. That was not the problem. The problem was getting pointed to the right dbghelp.dll file. Because the place Microsoft puts it has changed, and many articles about Process Explorer symbols do not address the Dbghelp.dll path, it took me a while to get this right.
I hope this article helps people. It is pretty in-depth for this task, and I hope educational, showing many things all in one place that I found in various places on the Internet and in my hands-on testing. Stay tuned for other articles of interest as I work through the book. It is proving to be fascinating and extremely helpful, both from the viewpoint of a developer and an administrator.