• Install the Debugging Tools for Windows (if you don’t already have them)
  • In Process Explorer, select Options | Configure Symbols... and configure as below:

Configure Symbols - Working

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


Above is a Symbols path with the symbol cache (d:\symbols) on the d: drive. Below is for the c: drive:


Select the local symbols cache folder you wish to have for your system as necessary (d:\symbols between the two asterisks above). My 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:

Process Explorer `Options | Configure Symbols...` menu

This is what the dialog box looks like the first time you use it:

Configure Symbols Dialogue Box - Initial

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 dbhelp.dll:

Configure Symbols Dialogue Box Ellipsis Button

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:

Configure Symbols Dbghelp.dll Only

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]*

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) is 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!):

Configure Symbols Working

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:

Process Explorer Main Window

Right click on a Windows process, and select Properties:

Process Explorer SearchUI.exe Popup Menu Properties

After the properties dialogue box comes up, select the Threads tab at the top:

SearchUI Properties Threads Tab

Not Yet Working

Before configuring symbols correctly, the output looks something like this:

SearchUI Properties Threads Initial

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.

Symbols Working

Below, you see the symbol server is working and the offset is resolved to a symbolic name (function name):

SearchUI.exe Properties Threads Working

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:

SearchUI.exe Properties Threads Working Stack Button

Stack trace without full symbols:

SearchUI Properties Threads Stack Initial

Stack trace with full symbols:

SearchUI Properties Threads Stack Working

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.

Final Tips

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.