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

To use the symbols for debugging we need to tell windbg which directories to look for these symbol files. To specify the symbol files path 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*http://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 command window 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*http://msdl.microsoft.com/download/symbols

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

.sympath


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


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.

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:\symbols\myapplication.pdb\38266E74B06B4EF3BCC16713A4A1E5E82\myapplication.pdb not found
SYMSRV:  http://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. Another thing you can notice 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 paths 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‘

0:041> .sympath+ c:\localsymbols
DBGHELP: Symbol Search Path: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\localsymbols
DBGHELP: Symbol Search Path: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\localsymbols
Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\localsymbols
Expanded Symbol search path is: srv*c:\symbols*http://msdl.microsoft.com/download/symbols;c:\localsymbols
0:041> .reload /f myapplication.exe
SYMSRV:  c:\symbols\myapplication.pdb\38266E74B06B4EF3BCC16713A4A1E5E82\myapplication.pdb not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/myapplication.pdb/38266E74B06B4EF3BCC16713A4A1E5E82/myapplication.pdb not found
DBGHELP: c:\localsymbols\myapplication.pdb – mismatched pdb
DBGHELP: c:\localsymbols\exe\myapplication.pdb – file not found
DBGHELP: c:\localsymbols\symbols\exe\myapplication.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.exe
DBGHELP: 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. This actually could be a genuine issue. If you see this issue, you need to crosscheck with your build numbers and pick up the right pdb file. If you have determined that the pdb file you are using is the right one and still seeing this message you can use /i switch to load the symbols even if there is no match.

0:041> .reload /i myapplication.exe
SYMSRV:  c:\symbols\myapplication.pdb\38266E74B06B4EF3BCC16713A4A1E5E82\myapplication.pdb not found
SYMSRV:  http://msdl.microsoft.com/download/symbols/myapplication.pdb/38266E74B06B4EF3BCC16713A4A1E5E82/myapplication.pdb not found
DBGHELP: c:\localsymbols\myapplication.pdb – mismatched pdb
DBGHELP: c:\localsymbols\exe\myapplication.pdb – file not found
DBGHELP: c:\localsymbols\symbols\exe\myapplication.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:\localsymbols\myapplication.pdb – unmatched

As you can see it looks for a matching pdb in all the search paths and loads the mismatched pdb in the end.

I hope this post has helped you in understanding how symbols loading works in Windbg. Let me know if you have any questions.