How do I debug .NET 4.6 framework source code in Visual Studio 2017?

21
votes

Here's what I've tried:

Made a new Console App (.NET Framework) in Visual Studio 2017.

Added the following code:

static void Main(string[] args)
{
    new Dictionary<int, int>().TryGetValue(3, out int x); //I want to step into TryGetValue() (this is just an example)
}

Configured the settings listed here: https://blogs.msdn.microsoft.com/sburke/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code/

Confirmed symbols are loaded in the Modules window:

mscorlib.dll Symbols loaded. 4.6.1586.0 built by: NETFXREL2

Tried: "Step Into (F11)"

Tried: "Step into Specific" | "System.Collections.Generic.Dictionary.TryGetValue"

Both just step over the line.

I've tried configuring VS using the details here: http://www.symbolsource.org/Public/Home/VisualStudio

Same result, the debugger steps over the line.

I've looked at the answer here: https://stackoverflow.com/a/12432029/297451

But this version doesn't seem to be a security update, and a search for "site:support.microsoft.com/kb 4.6.1586.0" yields nothing.

What am I doing wrong?

2
c#.netvisual-studio-debuggingdebug-symbolsvisual-studio-2017
Works just fine, looks like the reference source symbol server was in fact updated to 4.6.2. The hash code I get for mscorlib.dll is BEC17127F5324AE795428E84A11901182. Use the troubleshooting procedure I documented here. Empty the cache if necessary. - Hans Passant
@HansPassant Deleting the cached PDB solved the first issue, thanks (did I have a stripped PDB? How to tell?) I can now step into the function, but it's "Dictionary [from metadata]" and not source code. I have the same hash BEC17127F5324AE795428E84A11901182. - Jon
@HansPassant I still have a problem because it's not stepping through source code. "Dictionary [from metadata]" is just the interface, not the implementation. It's supposed to fetch the code on demand from source server. - Jon
Hmm, at this point you should of course show us the symbol trace you got. - Hans Passant
@HansPassant (removed a bunch of "Cannot find or open..."): SYMSRV: C:\symbols\mscorlib.pdb\BEC17127F5324AE795428E84A11901182\mscorlib.pdb - file not found SYMSRV: mscorlib.pdb from referencesource.microsoft.com/symbols: 11490816 bytes referencesource.microsoft.com/symbols: Symbols downloaded from symbol server. C:\symbols\mscorlib.pdb\BEC17127F5324AE795428E84A11901182\mscorlib.pdb: Symbols loaded. - Jon

2 Answers

16
votes

Here is the answer, thanks to Hans Passant. Note that this solution raises additional questions.

  1. Ensure https://referencesource.microsoft.com/ contains the exact version you're debugging.

  2. Configure Visual Studio as specified here: https://referencesource.microsoft.com/setup.html

    • Untick "Enable Just My Code"
    • Tick "Enable .NET Framework source stepping" (this should have been the only step needed)
    • Tick "Enable source server support"
    • Untick "Require source files to exactly match the original version"

  3. Confirm symbols are loaded in the Modules window, with source indexing included.

    • How can you tell if source indexing is included? The modules window doesn't specify if a PDB has stripped source information.

Microsoft could make this process a lot more robust by giving helpful error messages instead of silently failing.

10
votes

Use the Symbol Server feature in JetBrains dotPeek. Worked like a charm for me after struggling to get the standard functionality to work:

  1. Run dotPeek and go to Tools > Options... > Symbol Server.
  2. Ensure that "All assemblies" is selected and copy the local symbol server URL to the clipboard. Start the dotPeek symbol server by clicking it in the Tools menu.
  3. In Visual Studio, go to Tools > Options... > Debugging > Symbols and add the dotPeek server URL to the list. Move the dotPeek symbol server as high up the list as possible, and uncheck all other symbol servers in the list (in particular, the "Microsoft Symbol Servers" and "NuGet.org Symbol Server" must not be selected).
  4. Start debugging - when you attempt to step into Framework source code, you will see dotPeek doing some work decompiling the assembly for you, and then you will be into its source.

If this doesn't work, it's probably because Visual Studio has previously downloaded the "wrong" symbols for the assembly in question from Microsoft/NuGet, and is using them instead of asking dotPeek. To check this, start debugging and find the relevant assembly in the modules list (Debug > Windows > Modules) - delete the PDB file at the path displayed under "Symbol File" for that assembly, then restart debugging, and dotPeek should kick into action.