On Windbg and Symbols
Every once a while, a developer(SDE) or a tester(SDET) will find himself needing to look at dump files or debug a process. Here's what each debugger technology out there will support:
| Feature | KD | NTSD | WinDbg | Visual Studio .NET |
| Kernel-mode debugging | Y | N | Y | N |
| User-mode debugging | Y | Y | Y | |
| Unmanaged debugging | Y | Y | Y | Y |
| Managed debugging | Y | Y | Y | |
| Remote debugging | Y | Y | Y | Y |
| Attach to process | Y | Y | Y | Y |
| Detach from process in Win2K and XP | Y | Y | Y | Y |
| SQL debugging | N | N | N | Y |
My approach is to learn two debuggers to max my coverage: windbg and visual studio. Visual Studio's design is so good that you don't have to know anything about debugging to use it. So I want to talk a little bit regarding windbg, more specifically, troubleshooting its symbol problems.
PDBs are symbol files. The private variety contains type, local, global, and source line information. So provided that you have the private variety, how do you use them with a debugger to find out which line of the code you are currently executing? First, make sure you read the excellent article written by Saikat Sen at https://www.codeproject.com/KB/debug/windbg_part1.aspx. Instead of describing every step in detail, I will go over how to troubleshoot possible errors encountered regarding symbols.
First thing to try when symbols could not be loaded is to run the .reload command.
If that does not work, you could try to force all modules to reload by doing .reload -f. But chance of this working is low except in only certain situations. Instead we want to enable verbose symbol logging by running !sym noisy. What this does is making the symbol loading portion of windbg spit out more information than normal.
Now, do .reload again. Now you should see all the places that windbg is check for symbols in and how each attempt went. If you actually have the symbols, there are two possibilities that could happen.
Possibility #1: symbols and executable/image does not match. To solve this, either get good symbols or do .symopt+0x40 which forces the usage of the found symbol. This could give you bad info so keep that in mind.
Possibility #2: windbg doesn't look at the folder location that actually has your symbol. To fix this, do .sympath to see the symbol paths it's looking at, then do .sympath+ <path to symbol> to add the symbol directory to what's already there. You can also replace the symbol path by doing .sympath <path to symbol>.
Anyway, that's it for now. Hopefully I'll post more on this area in the future.