≡ Menu

Debugging using Windbg : Symbols loading

This post explains how to use program symbol files to debug applications or kernel drivers on Windows operating system. On Windows platform, the program symbols are stored in a separate file. These files are referred as pdb files and has the extension .pdb. When debugging a program in windbg, we need these symbol files otherwise what we see in the stack trace is just numerical addresses instead of function names and variable names. We won’t be able to make out anything from these numerical addresses. The symbols stored in pdb files are function names, local variable names, global variable names etc.

Setting symbol path

To use the symbols for debugging, we need to tell windbg which directories it should look into, to find the symbols. To do this, click on File menu and then Symbol File Path. You can enter the path as shown in the below image.

The symbol path in this example is srv*c:symbols*//msdl.microsoft.com/download/symbols.
The first path is a local directory and the second path is the Microsoft’s symbol server path. This path is required to get the symbols for Windows libraries like shell32.dll, gdi32.dll, advapi32.dll, kernel32.dll, ntdll.dll and many more libraries. The application we need to debug might be using these libraries.

We can specify the symbol search path in windbg prompt also. The command for this is .sympath
For example to set the above search path we need to run the below command.

.sympath srv*c:symbols*//msdl.microsoft.com/download/symbols

To print the current symbol search path just run .sympath command.

.sympath

Loading symbols after setting the path

After setting the symbol search path we need to load the symbols for all the loaded modules in memory. For this run the below command.

.reload /f

To load symbols for a particular binary we can specify the binary file name in the .reload command. For example to load symbols for myapplication.exe you can run the below command.

.reload /f myapplication.exe

In this command you need to provide the full name of the binary name along with the extension. Otherwise you might see the message like below.

“Myapplication” was not found in the image list.
Debugger will attempt to load “
Myapplication” at given base 00000000`00000000.

Please provide the full image name, including the extension (i.e. kernel32.dll)
for more reliable results.

Issues with symbols loading

If none of the symbol files match with the binary file then .reload command fails with the below error message.

0:041> .reload /f MyApplication.exe
*** ERROR: Module load completed but symbols could not be loaded for MyApplication.exe

When you get this do the following. Enable verbose mode for symbols loading by running the command !sym noisy. And run the .reload command again. Check for the error messages it prints.

0:041> !sym noisy
noisy mode – symbol prompts on
0:041> .reload /f myapplication.exe
SYMSRV: c:symbolsmyapplication.pdb38266E74B06B4EF3BCC16713A4A1E5E82myapplication.pdb not found
SYMSRV: //msdl.microsoft.com/download/symbols/myapplication.pdb/38266E74B06B4EF3BCC16713A4A1E5E82/myapplication.pdb not found
*** WARNING: Unable to verify checksum for myapplication.exe
*** ERROR: Module load completed but symbols could not be loaded for myapplication.exe
DBGHELP: myapplication – no symbols loaded

As you can see none of the symbol search paths have the Myapplication.pdb file. Before looking at how to fix this issue, let’s understand how windbg interpretes the symbol server path.

Understanding ‘SRV’ in symbol server path

Another thing you can notice in the above error is that, Windbg looks for the symbols files in a sub directory with the name myapplication.pdb/38266E74B06B4EF3BCC16713A4A1E5E82. This is because we used the keyword SRV in the symbol search path which indicates that this path need to be used as a symbol server path. For symbol servers, to identify the files path easily, Windbg uses the format binaryname.pdb/GUID. Each binary is given a unique GUID when the application is built and this GUID can be printed by the command !lmi binaryname. For example, to print GUID information for MyApplication.exe I need to run the command !lmi myapplication.

Now back to the symbol loading issue for Myapplication.exe. As the existing paths does not have this file, we need to add the path where the file is present. Let’s say the file is located at C:localsymbls. Then we can add this path to the symbols search using .sympath+ command. In our example, we need to run .symapth+ C:localsymbols. This is a normal directory which directly stores pdb files, it’s not a server path. So we don’t prefix the path with SRV.

0:041> .sympath+ c:localsymbols
DBGHELP: Symbol Search Path: srv*c:symbols*//msdl.microsoft.com/download/symbols;c:localsymbols
DBGHELP: Symbol Search Path: srv*c:symbols*//msdl.microsoft.com/download/symbols;c:localsymbols
Symbol search path is: srv*c:symbols*//msdl.microsoft.com/download/symbols;c:localsymbols
Expanded Symbol search path is: srv*c:symbols*//msdl.microsoft.com/download/symbols;c:localsymbols
0:041> .reload /f myapplication.exe
SYMSRV: c:symbolsmyapplication.pdb38266E74B06B4EF3BCC16713A4A1E5E82myapplication.pdb not found
SYMSRV: //msdl.microsoft.com/download/symbols/myapplication.pdb/38266E74B06B4EF3BCC16713A4A1E5E82/myapplication.pdb not found
DBGHELP: c:localsymbolsmyapplication.pdb – mismatched pdb
DBGHELP: c:localsymbolsexemyapplication.pdb – file not found
DBGHELP: c:localsymbolssymbolsexemyapplication.pdb – file not found

DBGHELP: Couldn’t load mismatched pdb for myapplication.exe

*** ERROR: Module load completed but symbols could not be loaded for myapplication.exeDBGHELP: myapplication – no symbols loaded

Now we are into another problem. Windbg detected the symbol file but it says that the symbol file is not matching with the exe file. Let’s see how to fix this in the next section.

Symbol file not matching

If you see this issue, you need to crosscheck with your build numbers and pick up the right pdb file. If you are sure that the pdb file you are using is the right one, but still seeing this message, then you can use /i switch to load the symbols even if there is no match.

0:041> .reload /i myapplication.exe
SYMSRV: c:symbolsmyapplication.pdb38266E74B06B4EF3BCC16713A4A1E5E82myapplication.pdb not found
SYMSRV: //msdl.microsoft.com/download/symbols/myapplication.pdb/38266E74B06B4EF3BCC16713A4A1E5E82/myapplication.pdb not found
DBGHELP: c:localsymbolsmyapplication.pdb – mismatched pdb
DBGHELP: c:localsymbolsexemyapplication.pdb – file not found
DBGHELP: c:localsymbolssymbolsexemyapplication.pdb – file not found

DBGHELP: Loaded mismatched pdb for myapplication.exe

DBGENG: myapplication.exe has mismatched symbols – type “.hh dbgerr003” for details
DBGHELP: myapplication – private symbols & lines
c:localsymbolsmyapplication.pdb – unmatched

As you can see it looks for a matching pdb in all the search paths. As it does not find any, it loads the mismatched pdb in the end.

I hope this post has helped you in understanding how symbols loading works in Windbg. If something is not clear to you, or if you have any other questions, please share it in the comments below.

Relevant posts:
Windbg commands reference
Download Windbg

{ 7 comments… add one }
  • Shivram June 8, 2012, 1:04 pm

    Hi !
    Thank you for such nice explanations with max possible details still in precise manner.

  • hbdivers2 June 23, 2012, 5:32 pm

    Hi,
    This is my second day learning Windbg using some crash dumps.
    I was looking for a way to force Windbg to load a pdb for a module.
    Your article hinted me on how to do it (even though the stack is clearly incorrect, which means the debugger was right in the first place)

    Thank you for this article.

  • marina August 8, 2012, 7:12 pm

    Thanks a lot!!
    Finally-the symbols have been loaded and everything works :))

  • jeevan April 15, 2013, 10:34 am

    how i get the symbol for outlook 2010 , i use the same URL which mentioned above but not able to get the symbol for outlook

    anybody help in this regards

  • Murad July 27, 2014, 10:14 pm

    1. General question. Does the symbol paths order matter? Does it help to make WinDbg more responsive if the app’s symbols are cited first?
    2. Sometimes stepping (F10) thru an app in WinDbg is painfully slow even if all symbols paths are correct and symbols are loaded. I have an impression that WinDbg is spending much time digging into the Windows system symbols.
    Since I am debugging my app only (and not the Windows), does it make WinDbg debugging faster if I provide my app’s symbols only? Is there a way telling WinDbg to reduce the scope of symbols matching to speed it up?

    • admin July 31, 2014, 4:23 pm

      Yes the order matters. The directory that has most of the symbols should be specified first.

  • Anonymous October 7, 2015, 9:42 am

    I am unable to load the symbols using
    .sympath+ D:gxrbin64

    The pdb file is present in D:gxrbin64 but it does not load the symbols

Leave a Comment