解决方法

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*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 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*http://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:\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. 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 formatbinaryname.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*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.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:\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. 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.