how deeply can the source path in windbg be nested?

Question

If I have multiple binaries whose sources are scattered in various subfolders of an overlaying folder, would windbg have access to them if only the topmost folder was included in Source Path? As opposed to having to reference each project folder of each relevant binary separately.

Assuming, of course, that the sources are unique in the mentioned folder structure, i.e. there are no multiple versions of one and the same project, source, etc.

Answer 1

If you specify the parent folder for the source files in source path then it should traverse through the subdirectories to find the source files.

Note that it will perform a signature match against your source files, in the same way that Visual studio will complain that the source files are different to the loaded dlls.

The relative locations of the source files must match the original locations so if your source files are located in a different structure then you will need to do a manual load/browse to specify the location of the source files.

Answer 2

Can’t answer exactly, but I often have 3 top (parent) directories, and each have approximately 4-5 levels of sub directories. No problems. However nothing beats using a source server

Answer 3

Short answer: NO.

From windbg's help:

For each directory in the symbol path, the debugger looks in three directories. For example, if the symbol path includes the c:\MyDir directory, and the debugger is looking for symbol information for a DLL, the debugger first looks in c:\MyDir\symbols\dll, then in c:\MyDir\dll, and finally in c:\MyDir. The debugger then repeats this process for each directory in the symbol path. Finally, the debugger looks in the current directory and then in the current directory with \dll appended to it. (The debugger appends dll, exe, or sys, depending on which binaries it is debugging.)

You can move all projects' .pdb files to one folder or change projects properties and setup the linker to create the .pdb file in a specific folder so you have to reference only one.

Answer 4

I've been doing a bit of debugging on this myself. From what I can tell, the relative path of the file found from the SourcePath needs to match part of the end path of the path embedded in the PDB. For example:

I have a file on disk at: C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust\library\std\src\sys\windows\thread_local_key.rs

The path of the file embedded in the PDB is: /rustc/c09a9529c51cde41c1101e56049d418edb07bf71\/library\std\src\sys\windows\thread_local_key.rs

✔ This SourcePath, and any below it, correctly finds the file: C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src\rust

❌ This SourcePath, and any above it, does not find the file: C:\Users\User\.rustup\toolchains\nightly-x86_64-pc-windows-msvc\lib\rustlib\src

Notice how with the failure case, the relative path to the file would begin with library\. The library path component is the first part of the path that is not found in the embedded path. I assume it does a path check for every relative address, recursively:

thread_local_key.rs
windows\thread_local_key.rs
sys\windows\thread_local_key.rs
src\sys\windows\thread_local_key.rs
std\src\sys\windows\thread_local_key.rs
library\std\src\sys\windows\thread_local_key.rs

etc.