Configuring Symbols RRS feed

  • Question

  • Is there a new guide to configuring Symbols in Process Explorer now that Microsoft have discontinued the offline Symbols? (which is annoying if you have a machine that can't go online).

    I've always struggled to get the Symbols to work. What am I doing wrong?

    Monday, October 15, 2018 11:27 AM


All replies

  • No one? Is this forum in use anymore?
    • Proposed as answer by slowtonyw Monday, October 22, 2018 6:52 PM
    • Unproposed as answer by slowtonyw Monday, October 22, 2018 6:52 PM
    Monday, October 22, 2018 10:31 AM
  • On 2018-10-22 the Windows Symbol Packages page describes this issue and the new Azure-based symbol store.

    If you can get your host online once, it says that the symbols from the online store are cached for offline use. 

    Alternatively, a process is described to request the needed symbols from a different host that is online. 

    Using a Manifest File with SymChk

    • Edited by slowtonyw Monday, October 22, 2018 7:06 PM
    Monday, October 22, 2018 7:04 PM
  • Thanks anyone know what I now put in the Configure Symbols section in Process Explorer

    So what do I put in Dbghelp.dll & in the Symbols Path:

    Currently I have 



    But I don't know if this is actually working or not. The c:\symbols\publics appears empty.

    Friday, October 26, 2018 12:40 PM
  • I have addressed this for the current state of my system after I finally got it working in the following article:

    Hope this helps.  Please let me know of any errors or problems so I can update the article appropriately, but also if it works for you as well.  It works for me.

    • Marked as answer by stevenwhiting Monday, July 22, 2019 10:29 PM
    • Edited by Xitalogy Friday, November 22, 2019 2:00 AM Updated Stale Link
    Saturday, July 20, 2019 7:30 AM
  • I think a little bit of history is necessary here..

    The system dbghelp.dll which is available in C:\windows\system32 is not a FULL debugging dll, but has been added in that position to help capturing stack traces for tools like the one from SysInternals, so that if you record a procmon trace and the read it on another machine where the FULL version of the dbghelp.dll is available, you can download symbols from the online Microsoft server or from an internal one and decode the captured stack traces.

    This was really valuable for customer that needed to send captured traces to Microsoft. For this reason the "less featured" DBGHELP.DLL is available in all windows version starting from Vista and Sysinternals tools point to it "by default".. so they can capture stack traces to be examined later onto another machine.

    SO,to recap, the DBGHELP.DLL that comes with the OS is able to capture stack traces but not to decode them using symbols.

    All the DBGHELP.DLL that come with Debugging tools/WDK/DDK atc.. can be used to decode stack traces and are able to work with symbols servers.


    Saturday, July 20, 2019 6:29 PM
  • Thanks. That's exactly what has been missing. The book even now points to old dead links as well and I never found it that clear if the symbols were being used or not as some of the entries looked the same. But got it working the other day but your post is perfect for a guide.

    One thing I'm slightly confused by is the dbghelp.dll. I'm sure I've heard Mark mentioning you need Symbols for x86 for x86 programs but the only option on Windows 10 is to point to the 64bit dbghelp file. If you attempt to point to the x86 file, you get an error because of course you're on a 64bit system. So does the 64bit dbghelp file, correctly show x86 symbols? Or will you only be seeing the incorrect 64bit symbols?

    Monday, July 22, 2019 10:35 PM
  • Certainly when you run the 32 bit version of the sysinternals tools, think to Procmon on a 32 bit system, you need to point to the 32 bit dbghelp.dll.

    So, it really depends on the bitness of the tool you are running.

    if you capture a 32 bit trace on a 32 bit system, then to open it on a 64 bit system you need to use the /run32 command line parameter to run procmon in 32 bit and at that point you will need to configure the dbghelp.dll x86 version in order to load 32 bit symbols correctly..

    or if you only run 32 bit systems there you will need the 32 bit dbghelp.dll.

    If you run procmon on a 64 bit system, the only option you have is to use 64 bit dbghelp.dll because procmon runs in 64 bit mode and load the 64 bit driver in the kernel, and in any case a 64 bit process can load only 64 bit dll (unless you use thunking and other technique which are useless here because the stack trace n any case comes from the kernel driver).

    SO, to sum up: 32 bit OS 32 bit procmon 32 bit dbghelp.dll
    64 bit OS 64 bit procmon to capture the trace and 64 bit dbghelp.dll to decode stacks
    64 bit os 32 bit procmon to load a 32 bit trace captured on another machine , and 32 bit dbghelp.dll to decode the stack traces.


    Tuesday, July 23, 2019 7:33 AM
  • So surely that then means most of the apps we're running into on a daily bases that are only 32bit apps but run on 64bit Windows 10 will be showing incorrect symbols. For example at work we only run the 32bit version of Office. So I assume now that means all the stack and thread symbols (or is it only on the stack) the symbols shown are inaccurate as they are showing 64bit Symbols only and not the 32bit symbols of that office app?

    Although looking at this image I've just taken I see some 32bit info showing. With the WOW64 mentioned.

    Tuesday, July 23, 2019 8:40 AM
  • Unfortunately yes.. you will see the user mode 32 bit stack without resolution, while when it switch to 64 bit and enter the kernel, that will be correct.

    Only in windbg you will be able to completely resolve the stack even if it is mixed between 32 and 64 bit..

    Just in case, you can create a windows 10 32 bit virtual machine where run 32 bit office when you have troubles..


    Tuesday, July 23, 2019 10:04 AM
  • Cool, thanks.
    Tuesday, July 23, 2019 12:39 PM
  • Please, disregard my latest statement, I didn't have my second disk attached.. now that I have, it correctly download the symbols file and resolve function name and address..

    So, on a 64 bit OS the dbghelp.dll at 64 bit can download symbols and resolve function name and address for a 32 bit application.. given that your symbol path is correctly configured.. 


    Tuesday, July 23, 2019 1:01 PM