Enable navigation to decompiled sources not working

[vsfeedback]

This issue has been moved from a ticket on Developer Community.

---

[severity:It's more difficult to complete my work] The "Enable navigation to decompiled sources" option under "Options" => "Text Editor" => "C#" => "Advanced" => "Go To Definition" has stopped working for me. I have had it disabled since updating to Visual Studio 2022, because I so in-frequently want to look at decompiled source. Occasionally, when I do want to look at source, I will turn the option back on, temporarily, and it has always worked fine that way. Today, turning the option back on is not working, even after restarting Visual Studio.

---

Original Comments

Feedback Bot on 6/28/2023, 00:51 AM:

(private comment, text removed)

Feedback Bot on 7/5/2023, 09:01 AM:

(private comment, text removed)

---

Original Solutions

(no solutions)

[JakenVeina]

This issue has resurfaced for me today, after updating to 17.9.6.

[CyrusNajmabadi]

@JakenVeina can you describe what is happening for you?

[JakenVeina]

Quite simply, "Enable navigation to Source Link and Embedded sources", "Enable navigation to decompiled sources", and "Always use default symbol servers for navigation" are all still checked, within options, but "Go to Definition" on various types, such as System.Collections.Generic.List<> no longer pulls up a decompilation, just a metadata file.

[CyrusNajmabadi]

@davidwengier are tehre any logs emitted that might help out here?

Also, just so i understand, what's our behavior with ref-assemblies? Do we bother decompiling? Or do we just go to metadata-as-source.

@JakenVeina can you show us the #region at the top of your metadata file?

[CyrusNajmabadi]

Navigating to List<> works for me:

Will need some more information from David in terms of figuring out what might be going on here.

[davidwengier]

@JakenVeina If you open the Output window in VS, and look for "Navigation to External Sources" in the dropdown, and paste the contents in here, that should tell us what is going on.

What can happen is that if you have recently installed a new .NET SDK, your references could be coming from a nuget package that doesn't have any source information. At runtime the .NET host redirects things to use the SDK you have installed, but during development time all Roslyn knows about is the reference assemblies that the SDK has decided your project should reference, so it falls back to metadata.

Also, just so i understand, what's our behavior with ref-assemblies? Do we bother decompiling? Or do we just go to metadata-as-source.

We try to find the implementation assemblies, using a couple of heuristics for nuget packages and for SDK targeting packs, but if we can't find them, we go to metadata-as-source. The output window logs should show what is going on though.

[davidwengier]

See also https://github.com/dotnet/roslyn/issues/24349#issuecomment-1712966486 (and probably close as a dupe, if the output window logs confirm)

[JakenVeina]

Navigating to symbol 'System.Collections.Generic.List<T>' from 'System.Collections'.
Symbol found in assembly path 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.4\ref\net8.0\System.Collections.dll'
Symbol found in assembly path 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.4\System.Collections.dll'
Symbol found in assembly path 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.4\System.Private.CoreLib.dll'
Cannot find or open the PDB file.
Cannot find or open the PDB file.
Could not find PDB on disk, or embedded, or on a symbol server.

For reference, the symbol servers that I have configured under "Debugging" => "Symbols" are "Microsoft Symbol Servers" and "NuGet.org Symbol Servers", which are the defaults, are they not?

After perusing the linked thread, I'll also mention that this is a .NET 8 project, with 8.0.204 being the installed SDK on this system.

It does appear that VS is falling back to the reference assemblies, as the metadata file itself reports...

#region Assembly System.Collections, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.4\ref\net8.0\System.Collections.dll
#endregion

The logs to me, though, seem to suggest that VS also did find non-reference implementations, and just failed to use them, for some reason.

If it is just that VS can't find the true assemblies to decompile, is there any shuffling I can do on my end to work around this? I'm also curious why the symbol servers seem to be failing.

Thanks for your time, all.

[davidwengier]

Thanks for the logs @JakenVeina. Looks like Roslyn is doing everything good here, and finding impl assemblies correctly. I wonder if you're hitting the same debugger bug as in https://github.com/dotnet/roslyn/issues/72638. There is a workaround posted in https://github.com/dotnet/roslyn/issues/72638#issuecomment-2035288691 for that which you could try.

There is possibly a bug in Roslyn here too though, since we found an implementation assembly, you probably should have seen decompiled code and not metadata, but I might be misremembering about how this code path works.

[JakenVeina]

Wiping out %TMP%/SymbolCache doesn't seem to solve the issue. The folder gets re-populated with...

System.Private.CoreLib.pdb
pingme.txt

...on my next execution of "Go to Definition", after restarting Visual Studio (that .pdb being a folder, not a file). Furthermore, the "Navigation to External Sources" now shows...

Navigating to symbol 'System.Collections.Generic.List<T>' from 'System.Collections'.
Symbol found in assembly path 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.4\ref\net8.0\System.Collections.dll'
Symbol found in assembly path 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.4\System.Collections.dll'
Symbol found in assembly path 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.4\System.Private.CoreLib.dll'
Timed out trying to download PDB from symbol server. Subsequent requests may succeed.
More data is available. (Exception from HRESULT: 0x800700EA)
   at Microsoft.VisualStudio.Debugger.BrokeredServices.SymbolLocator.Com.ISymbolLocator159.LocateAnyFormatPdbWithChecksums(PdbInfo159& pdbFile, Object pMetadataProvider, String additionalSearchPaths, UInt32 symbolLoadingOptions)
   at Microsoft.VisualStudio.Debugger.BrokeredServices.SymbolLocator.SymbolLocatorService.<LocateSymbolFileAsync>d__2.MoveNext()

Edit: Seems to be working now, after a little bit of time.

Navigating to symbol 'System.Collections.Generic.List<T>' from 'System.Collections'.
Symbol found in assembly path 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.4\ref\net8.0\System.Collections.dll'
Symbol found in assembly path 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.4\System.Collections.dll'
Symbol found in assembly path 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.4\System.Private.CoreLib.dll'
Found PDB on symbol server.
'/_/src/libraries/System.Private.CoreLib/src/System/Collections/Generic/List.cs' found via SourceLink.

Seems like it just needed to re-sync with SourceLink. I don't know why that was failing earlier, it's not like I was having any other internet trouble.

[daveclements]

I ran into the same issue, but it appears to have had a different cause - the default Symbol file locations had been deselected (Debugging => Symbols)

not sure what caused this to happen as it definitely wasn't done deliberately, but selecting them both resolved the issue for me

[cremor]

the default Symbol file locations had been deselected (Debugging => Symbols)

not sure what caused this to happen as it definitely wasn't done deliberately

I think they are not selected by default. See also https://github.com/dotnet/roslyn/issues/72638#issuecomment-2025785058

[fitdev]

Facing the same issue with VS 17.11 P2:

Navigating to symbol 'System.DateTime' from 'System.Runtime'.
Symbol found in assembly path 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.5\ref\net8.0\System.Runtime.dll'
Symbol found in assembly path 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.5\System.Runtime.dll'
Symbol found in assembly path 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.5\System.Private.CoreLib.dll'
Cannot find or open the PDB file.
https://msdl.microsoft.com/download/symbols: Symbols not found on symbol server.
https://symbols.nuget.org/download/symbols: Symbols not found on symbol server.

And the contents of my System.Private.CoreLib.pdb subdir in Symbol Cache (each containing a single System.Private.CoreLib.pdb file):

68B264DD7CC4C2C3C3019A8F69C829E0ffffffff
84DE8480EB34C767634123564E7C1D2Dffffffff
8E8E1DD0AEE7454B2F8EF5EA166E4043ffffffff
9DE4E8DDF81E101FC5297E6A380F3614ffffffff
E3C644B73A54810F355A8F0328265E5Bffffffff

There is no symsrv.miss.txt at the root of Symbol Cache folder either.

[kirsan31]

Same issue here after updating from 17.10.5 to 17.11.5.

Navigating to symbol 'string.Insert(int, string)' from 'System.Runtime'.
Symbol found in assembly path 'C:\Program Files\dotnet\packs\Microsoft.NETCore.App.Ref\8.0.10\ref\net8.0\System.Runtime.dll'
Symbol found in assembly path 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.10\System.Runtime.dll'
Symbol found in assembly path 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.10\System.Private.CoreLib.dll'
Cannot find or open the PDB file.
https://msdl.microsoft.com/download/symbols: Skipped checking location. The symbol file was not found in this location before.
https://symbols.nuget.org/download/symbols: Skipped checking location. The symbol file was not found in this location before.

Could not find PDB on disk, or embedded, or on a symbol server.

symsrv.miss.txt was at the root of Symbol Cache folder, but deleting it not solve the problem. In 17.10.5 all worked fine.

Skipped checking location. The symbol file was not found in this location before.

How to force to refresh this? Is this generally a good approach to skip sources after one not found?