Debugger doesn't find PDBs in their original built location

[braunsonm]

Environment data

dotnet --info output:

.NET Command Line Tools (2.1.202)

Product Information:
 Version:            2.1.202
 Commit SHA-1 hash:  281caedada

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.202\

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.9
  Build    : 1632fa1589b0eee3277a8841ce1770e554ece037

VS Code version: Latest Stable
C# Extension version: 1.15.2

Steps to reproduce

Opening a root workspace with a .sln and a Source/ folder. Build into Output/Debug. However the launch PDB's build into Source/PROJNAME/obj/Debug/PROJNAME.pdb but is not detected by the extension as I believe it is looking in the Output/Debug folder.

Expected behavior

The extension should check the directory from which the source was built.

Actual behavior

It fails to find the PDB's.

Loaded 'E:\Development\Example\Output\Debug\bridge\runtime\test1.dll'. Cannot find or open the PDB file.
Loaded 'E:\Development\Example\Output\Debug\bridge\runtime\test2.dll'. Cannot find or open the PDB file.

PDB can be found in:

'E:\Development\Example\Source\test1\obj\Debug\test1.pdb
E:\Development\Example\Source\test2\obj\Debug\test2.pdb

I've tried to set the symbolOptions to:

        {
            "name": "Attach",
            "type": "coreclr",
            "request": "attach",
            "processName": "server.exe",
            "symbolOptions": {
                "searchPaths": ["$(workspaceRoot)/Source/../obj/Debug"],
                "searchMicrosoftSymbolServer": false
            },
        }

Without success.

[gregg-miskelly]

The default search locations will be: the original location where the compiler dropped the PDB and next to the dll. If you have full Visual Studio installed with the C++ work load, there is a tool called 'dumpbin' in there that will let you see what this original directory is -- from a VS developer command prompt run dumpbin /headers <path-to-dll> | findstr RSDS.

I am not sure why adding the directory to searchPaths wouldn't work though. If you explicitly add the full path (no '..') does it work?

[braunsonm]

Thanks for the reply!
I have the C# workload installed not the C++ one but I can't seem to run dumpbin. If what you say is true about it checking the original location the compiler placed it then it should be able to find it in obj/Debug shouldn't it?

Interestingly looking closer at the output when I attach I see this:

WARNING: Symbol search directory '$(workspaceRoot)\Source\..\obj\Debug' is an invalid fully qualified directory name and was ignored.
WARNING: Could not load symbols for 'test1.dll'. 'E:\Development\Example\Source\test1\obj\Debug\test1.pdb' is a Windows PDB. These are not supported by the cross-platform .NET Core debugger.
Loaded 'E:\Development\Example\Output\Debug\bridge\runtime\test1.dll'. Cannot find or open the PDB file.

I was able to fix the first issue by adjusting my search path to use workspaceFolder instead.

As per your request I set my search path to:

"searchPaths": ["${workspaceFolder}/Source/test2/obj/Debug"],

But I still get the error:

Loaded 'E:\Development\Example\Output\Debug\bridge\runtime\test2.dll'. Cannot find or open the PDB file.

Just want to note that the exact same solution, attaching the debugger works without issues and without extra configuration in VS. @gregg-miskelly

[gregg-miskelly]

Are you getting any other messages for test2.dll/pdb? For example, do you get the error about it being a Windows PDB? (... is a Windows PDB. These are not supported by the cross-platform .NET Core debugger.)

[braunsonm]

Sorry for all the spam. I found the issue.

OmniSharp looks in the obj/Debug/ directory but does NOT look in obj/Debug/netcoreapp2.0 where it is actually stored.

Anything I can do on my end to resolve this? Using ${workspaceFolder}/Source/../obj/Debug/netcoreapp2.0 doesn't work because some directories in Source/ aren't csproj folders at all and don't have that pathing so it seems to just fail for all of them.

(The windows PDB was unrelated, it was an old file in the wrong place)

[braunsonm]

Hey @gregg-miskelly any update on this or if it's something I can simply create an PR for?

[gregg-miskelly]

@Chaosca sorry I didn't get back to you earlier. If you are still interested in looking at this - I would need the output of dumpbin /headers <path-to-dll> | findstr RSDS to tell you more.. If you could install the C++ Workload temporarily into VS, or just send me your dll then we can see if we can understand what is going wrong.

[braunsonm]

Hey @gregg-miskelly

Still very much interested in helping out and can do. However I don’t believe it’s an issue of my DLL, since it works properly if I add the correct directory to searchPaths. The issue is that the extension only looks in obj/Debug and does not look in obj/Debug/netcoreapp2.0 for the project. Since our solution has many projects it’s difficult/annoying to add all of them as a search path.

If still needed I can get you that dumpbin however.

[gregg-miskelly]

@Chaosca Yes, the dumpbin output would be helpful.

[braunsonm]

E:\Development\Example\Source\test1\obj\Debug\netcoreapp2.0>dumpbin /headers test1.dll | findstr RSDS
    9B8DA32C cv            65 00006810     4A10    Format: RSDS, {1FE11D8D-CF96-4C70-ACFC-B14B549C7F97}, 1, E:\Development\Example\Source\test1\obj\Debug\netcoreapp2.0\test1.pdb

@gregg-miskelly

[gregg-miskelly]

Thanks. Is E:\Development\Example\Source\test1\obj\Debug\netcoreapp2.0\test1.pdb the path where your PDB is? (the path that you are adding to your search path)

[braunsonm]

Yes that has the correct PDB file that works properly when manually added to the search path :)

[gregg-miskelly]

If you leave your symbolOptions empty, do you get any log lines in the debug console that talks about test1?

If that doesn't show anything - try this:

1. Download and run Process Monitor
2. In process monitor, bring up the filter dialog, and add a filter for 'Process Name' is 'vsdbg-ui.exe'
3. Make sure that Filter->Drop Filtered Events is checked
4. Start collection
5. Try to debug with symbolOptions empty
6. Turn off collection
7. Search for 'test1.pdb' in the collected log, and see if anything interesting is happening. You can just email me the log if you like. I am 'greggm' on the microsoft.com email server.

[braunsonm]

Nothing interesting in the debug console except for the lines I showed above how it cannot be found.

I shot you an email with the log file! @gregg-miskelly

[gregg-miskelly]

Thanks to help from @Chaosca, I was able to find the problem. Thanks!

[braunsonm]

Awesome! Can't wait for a fix

[braunsonm]

Hey @gregg-miskelly anything I can do to help get this through?
Thanks!

[gregg-miskelly]

I hope to put out a new beta tomorrow that will have the fix for this.

[gregg-miskelly]

1.17.0-beta6 is now on the release page. Please follow these instructions to install.

[braunsonm]

Works! Thanks again @gregg-miskelly