Windows Internals: How to Configure Symbols in Sysinternals' Process Explorer

Summary of Steps Needed

• Install the Debugging Tools for Windows (if you don’t already have them)
• Create a directory in which to store your debugging symbols (e.g., c:\symbols or d:\symbols)
• In Process Explorer, select Options | Configure Symbols... and configure as below:

First, here is the Dbghelp.dll path:

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\dbghelp.dll

Next, the Symbols path if you wish to use the C: drive:

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

Or, the Symbols path if you wish to use the D: drive.:

srv*d:\symbols*https://msdl.microsoft.com/download/symbols

In the picture above, I show the path to the local symbols cache (between the asterisks in the Symbols path) on the D: drive. This is because my C: drive is short on space, and the the local symbols cache can get very big, many gigabytes. You can call it whatever you want, and put it wherever is expedient for you. A local drive is best for speed.

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.

---

Introduction

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

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:

srv*d:\symbols*https://msdl.microsoft.com/download/symbols

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. For instance:

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

You will have to create the symbols directory yourself - Process Explorer will not make it for you. The symbol cache can get quite large (many gigabytes), so make sure you have plenty of 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 Dgbhelp.dll path which starts as below on my computer. Many older articles point to such a path 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:

SearchUI.exe+Ox120cd0

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

Now, we see not just the offset, but the actual function name:

SearchUI.exe!WinMainCRTStartup

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.

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

Conclusion

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.